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CHAPTER  1 
INTRODUCTION 


The  Ada  implementation  described  above  was  tested  according  to  the  Ada  Validation  Procedures 
[Pro90]  against  the  Ada  Standard  [Ada83]  using  the  current  Ada  Compiler  Validation  Capability 
(ACVC).  This  Validation  Summary  Report  (VSR)  gives  an  account  of  the  testing  of  this  Ada 
implementation.  For  any  technical  terms  used  in  this  report,  the  reader  is  referred  to  [Pro90].  A 
detailed  description  of  the  ACVC  may  be  found  in  the  current  ACVC  User’s  Guide  [UG89]. 


1.1  USE  OF  THIS  VAUDATION  SUMMARY  REPORT 

Consistent  with  the  national  laws  of  the  originating  country,  the  Ada  Certification  Body  may  make 
full  and  free  public  disclosure  of  this  report.  In  the  United  States,  this  is  provided  in  accordance  with 
the  "Freedom  of  Information  Act"  (S  U.S.C.  #552).  The  results  of  this  validation  apply  only  to  the 
computers,  operating  systems,  and  compiler  versions  identified  in  this  report. 

The  organisations  represented  on  the  signature  page  of  this  report  do  not  represent  or  warrant  that 
all  statements  set  forth  in  this  report  are  accurate  and  complete,  or  that  the  subject  implementation 
has  no  nonconformities  to  the  Ada  Standard  other  than  those  presented.  Copies  of  this  report  are 
available  to  the  public  from  the  AVF  which  performed  this  validation  or  from; 

National  Technical  Infomiation  Service 
5285  Port  Royal  Road 
Springfleld 
VA  22161 

Questions  regarding  this  report  or  the  validation  test  results  should  be  directed  to  the  AVF  which 
performed  this  validation  or  to: 

Ada  Validation  Organisation 
Institute  for  Defense  Analyses 
1801  North  Beauregard  Street 
Alexandria 
VA  22311 
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1.2  REFERENCES 

[Ada831  Reference  Manual  for  the  Ada  Programming  Language. 

ANSI/MIL-STD-1815A,  February  1983  and  ISO  8652-1987 

(Pro90j  Ada  Compiler  Validation  Procedures. 

Version  2.1,  Ada  Joint  Program  Office,  August  1990 

[UG89)  Ada  Compiler  Validation  Capability  User’s  Guide. 

21  June  1989. 


1.3  ACVC  TEST  CLASSES 

Compliance  of  Ada  implementations  is  tested  by  means  of  the  ACVC.  The  ACVC  contains  a 
collection  of  test  programs  structured  into  six  test  classes;  A.  B,  C,  D,  E,  and  L.  The  first  letter  of 
a  test  name  identifies  the  class  to  which  it  belongs.  Class  A,  C,  D,  and  E  tests  are  executable.  Class 
B  and  class  L  tests  are  expected  to  produce  errors  at  compile  time  and  link  time,  respectively. 

The  executable  tests  are  written  in  a  self-checking  manner  and  produce  a  PASSED,  FAILED,  or 
NOT  APPLICABLE  message  indicating  the  result  when  they  are  executed.  Three  Ada  library  units, 
the  packages  REPORT  and  SPPRT13,  and  the  procedure  CHECK_FILE  are  used  for  this  purpose. 
The  package  REPORT  also  provides  a  set  of  identity  functions  used  to  defeat  some  compiler 
optimizations  allowed  by  the  Ada  Standard  that  would  circumvent  a  test  objective.  The  package 
SPPRT13  is  used  by  many  tests  for  Chapter  13  of  the  Ada  Standard.  The  procure  CHECK_FILE 
is  used  to  check  the  contents  of  text  files  written  by  some  of  the  Class  C  tests  for  Chapter  14  of  the 
Ada  Standard.  The  operation  of  REPORT  and  CHECK_FILE  is  checked  by  a  set  of  executable  tests. 
If  these  units  are  not  operating  correctly,  validation  testing  is  discontinued. 

Class  B  tests  check  that  a  compiler  detects  illegal  language  usage.  Class  B  tests  are  not  executable. 
Each  test  in  this  class  is  compUed  and  the  resalting  compilation  listing  is  examined  to  verify  that  all 
violations  of  the  Ada  Standard  are  detected.  Some  of  the  class  B  tests  contain  legal  Ada  code  which 
must  not  be  flagged  illegal  by  the  compiler.  This  behaviour  is  also  verified. 

Class  L  tests  check  that  an  Ada  implementation  correctly  detects  violation  of  the  Ada  Standard 
involving  multiple,  separately  compiled  units.  Errors  are  expected  at  link  time,  and  execution  is 
attempted. 

In  some  tests  of  the  ACVC,  certain  macro  strings  have  to  be  replaced  by  implementation-specific 
values  -  for  example,  the  largest  integer.  A  list  of  the  values  used  for  this  implementation  is 
provided  in  Appendix  A.  In  addition  to  these  anticipated  test  modifications,  additional  changes  may 
be  required  to  remove  unforeseen  conflicts  between  the  tests  and  implementation-dependent 
characteristics.  The  modifications  required  for  this  implementation  are  described  in  section  2.3. 
For  each  Ada  implementation,  a  customized  test  suite  is  produced  by  the  AVF.  This  customization 
consists  of  making  the  modifications  descnbed  in  the  preceding  paragraph,  removing  withdrawn  tests 
(see  section  2.1)  and,  possibly  some  inapplicable  tests  (see  Section  3.2  and  [UG89J). 
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In  order  to  pass  an  ACVC  an  Ada  implementation  must  process  each  test  of  the  customized  test  suite 
according  to  the  Ada  Standard. 


1.4  DEnNinON  OF  TERMS 

Ada  Compiler  The  software  and  any  needed  hardware  that  have  to  be  added  to  a 

given  host  and  target  computer  system  to  allow  transformation  of 
Ada  programs  into  executable  form  and  execution  thereof. 

Ada  Compiler  The  means  for  testing  compliance  of  Ada  implementations,  consisting 

Validation  of  the  test  suite,  the  support  programs,  the  ACVC  user’s  guide  and 

Capability  (ACVC)  the  template  for  the  validation  summary  report. 

Ada  Implementation  An  Ada  compiler  with  its  host  computer  system  and  its  target 

computer  system 

Ada  Joint  Program  The  part  of  the  certification  body  which  provided  policy  and  guidance 

Office  (AJPO)  for  the  Ada  Certification  system. 

Ada  Validation  Facility  The  part  of  the  certification  body  which  carries  out  the  procedures 

(AVF)  required  to  establish  the  compliance  of  an  Ada  implementation. 

Ada  Validation  The  part  of  the  certification  body  that  provides  technical  guidance  for 

Organisation  (AVO)  operations  oC  the  Ada  Certification  system. 

Compliance  of  an  Ada  The  ability  of  the  implementation  to  pass  an  ACVC  version. 

Implementation 

Computer  System  A  functional  unit,  consisting  of  one  or  more  computers  and 

associated  software,  that  uses  common  storage  for  all  or  part  of  a 
program  and  also  for  all  or  part  of  the  data  necessary  for  the 
execution  of  the  program;  executes  user-written  or  user-designated 
programs;  performs  user-designated  data  manipulation,  including 
arithmetic  operations  and  logic  operations;  and  that  can  execute 
programs  that  modify  themselves  during  execution.  A  computer 
system  may  be  a  stand-alone  unit  or  may  consist  of  several  inter¬ 
connected  units. 

Conformity  Fulfilment  by  a  product,  process  or  service  of  all  requirements 

specified. 

Customer  An  individual  or  corporate  entity  who  enters  into  an  agreement  with 

an  AVF  which  specifies  the  terms  and  conditions  for  AVF  services 
(of  any  kind)  to  be  performed. 


ValMaUoo  Sonuiiary  Report  AVF_VSR_90S0Z/73 


SD-Sctcon  UK  Umlted 


Chapter  1  -  Page  3  of  4 


XD  Ada  MC6S00  Venlon  1.2 


INTRODUCTION 


Declaration  of 
Conformance 

Host  Computer  System 

Inapplicable  test 

ISO 

Operating  System 

Target  Computer 
System 

Validated  Ada  Compiler 

Validated  Ada 
Implementation 

Validation 

Withdrawn  test 


ValidattoD  Samimiry  Report 


A  formal  statement  from  a  customer  assuring  that  conformity  is 
realized  or  attainable  on  the  Ada  implementation  for  which 
validation  status  is  realized. 

A  computer  system  where  Ada  source  programs  are  transformed  into 
executable  form. 

A  test  that  contains  one  or  more  test  objectives  found  to  be 
irrelevant  for  the  given  Ada  implementation. 

International  Organisation  for  Standardisation. 

Software  that  controls  the  execution  of  programs  and  that  provides 
services  such  as  resource  allocation,  scheduling,  input/output  control, 
and  data  management.  Usually,  operating  systems  are  predominantly 
software,  but  partial  or  complete  hardware  implementations  are 
possible. 

A  computer  system  where  the  executable  form  of  Ada  programs  are 
executed. 

The  compiler  of  a  validated  Ada  implementation. 

An  Ada  implementation  that  has  been  validated  successfully  either 
by  AVF  testing  or  by  registration  [ProWj. 

The  process  of  checking  the  conformity  of  an  Ada  compiler  to  the 
Ada  programming  language  and  of  issuing  a  certificate  for  this 
implementation. 

A  test  found  to  be  incorrect  and  not  used  in  conformity  testing.  A 
test  may  be  incorrect  because  it  has  an  invalid  test  objective,  fails  to 
meet  its  test  objective,  or  contains  erroneous  or  illegal  use  of  the 
Ada  programming  language. 
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CHAPTER  2 


IMPLEMENTATION  DEPENDENCIES 
2.1  WITHDRAWN  TESTS 

The  following  tests  have  been  withdrawn  by  the  AVO.  The  rationale  for  withdrawing  each  test  is 
available  from  either  the  AVO  or  the  AVF.  The  publication  date  for  this  list  of  withdrawn  tests  is 
91-02-25. 


E28005C 

B28006C 

C34006D 

C35508I 

C35508J 

C35508M 

C35508N 

C35702A 

B41308B 

C43004A 

C45114A 

C45346A 

C45612A 

C45612B 

C45612C 

C45651A 

C46022A 

B49008A 

A74006A 

C74308A 

B83022B 

B83022H 

B83025B 

B83025D 

B83026B 

C83026A 

C83041A 

B85001L 

C86001F 

C94021A 

C97116A 

C98003B 

BA2011A 

CB7001A 

CB7001B 

CB7004A 

CC1223A 

BC1226A 

CC1226B 

BC3009B 

BD1B02B 

BD1B06A 

AD1B08A 

BD2A02A 

CD2A21E 

CD2A23E 

CD2A32A 

CD2A41A 

CD2A41E 

CD2A87A 

CD2B15C 

BD3006A 

BD4008A 

CD4022A 

CD4022D 

CD4024B 

CD4024C 

CD4024D 

CD4031A 

CD4051D 

CD5111A 

CD7004C 

ED7005D 

CD7005E 

AD7006A 

CD7006E 

AD7201A 

AD7201E 

CD7204B 

AD7206A 

BD8002A 

BD8004C 

CD9005A 

CD9005B 

CDA201E 

CE2107I 

CE2117A 

CE2117B 

CE2119B 

CE2205B 

CE2405A 

CE3111C 

CE3116A 

CE3118A 

CE3411B 

CE3412B 

CE3607B 

CE3607C 

CE3607D 

CE3812A 

CE3814A 

CE3902B 

2.2  INAPPUCABLE  TESTS 


A  test  is  inapplicable  if  it  contains  test  objectives  which  are  irrelevant  for  a  given  Ada 
impiementation.  Reasons  for  a  test’s  inapplicability  may  be  supported  by  documents  issued  by  the 
ISO  and  AJPO  known  as  Ada  Commentaries  and  commonly  referenced  in  the  format  Al-ddddd.  For 
this  implementation,  the  following  tests  were  determined  to  be  inapplicable  for  the  reasons  indicated; 
references  to  Ada  Commentaries  are  included  as  appropriate. 


The  following  159  tests  have  floating-point  type  declarations  requiring  more  digits  than 
SYSTEM.MAX_DIGITS: 


C241130..Y  (11  tests) 
C35706O..Y  (11  tests) 
C35708O..Y  (11  tests) 
C452410..Y  (11  tests) 
C454210..Y  (11  tests) 
C455240..Z  (12  tests) 
C456410..Y  (11  tests) 


C35705O..Y  (11  tests) 
C35707O..Y  (11  tests) 
C35802O..Z  (12  tests) 
C453210..Y  (11  tests) 
C455210..Z  (12  tests) 
C456210..Z  (12  tests) 
C46012O..Z  (12  tests) 
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The  following  20  tests  check  for  the  predefined  type  LONG_INTEGER: 


C35404C 

C45231C 

C45304C 

C45411C 

C45412C 

C45502C 

C45503C 

C45504C 

C45504F 

C45611C 

C45613C 

C45614C 

C45631C 

C45632C 

B52004D 

C55B07A 

B55B09C 

B86001W 

C86006C 

CD7101F 

C35713B,  C45423B,  B86001T,  and  C86006H  check  for  the  predefined  type  SHORT_FLOAT. 

C45423A,  C45523A  and  C45622A  check  that  if  MACHINE_OVERFLOWS  is  TRUE  and  the  results 
of  various  floating-point  operations  lie  outside  the  range  of  the  base  type,  then  the  proper  exception 
is  raised.  For  this  implementation,  MACHINE_OVERFLOWS  is  FALSE. 

C45531M..P  (4  tests)  and  C45532M..P  (4  tests)  check  fixed-point  operations  for  types  that  require  a 
SYSTEM.MAX_MANT1SSA  of  47  or  greater. 

B86001Y  checks  for  a  predefined  fixed-point  type  other  than  DURATION. 

C96005B  checks  for  values  of  type  DURATION’BASE  that  are  outside  the  range  of  DURATION. 
There  are  no  such  values  for  this  implementation. 

CD1009C  uses  a  representation  clause  specifying  a  non-default  size  for  a  floating-point  type. 

CD2A84A,  CD2A84E,  CD2A84I.J  (2  tests),  and  CD2A840  use  representation  clauses  specifying 
non-default  sizes  for  access  types. 

CD2B15B  checks  that  STORAGE_ERROR  is  raised  when  the  storage  size  specified  for  a  collection 
is  too  small  to  hold  a  single  value  of  the  designated  type;  this  implementation  allocates  more  space 
than  was  specified  by  the  length  clause,  as  allowed  by  AI-00558. 

The  following  264  tests  check  for  sequential,  text,  and  direct  access  files; 


CE2102A..C  (3) 
CE2103C..D  (2) 
CE2107A..H  (8) 
CE2110A..D  (4) 
CE2201A..C  (3) 
CE2204A..D  (4) 
CE2401A..C  (3) 
CE2401H..L  (5) 
CE2406A 
CE2410A..B  (2) 
CE3102J..K  (2) 
CE3107B 
CE3111A..B  (2) 
CE3115A 
CE3207A 


CE2102G..H  (2) 

CE2104A..D  (4) 

CE2107L 

CE2111A..1  (9) 

EE2201D..E  (2) 

CE2205A 

EE2401D 

CE2403A 

CE2407A  B  (2) 

CE24nA 

CE3103A 

CE3108A..B  (2) 

CE3111D..E  (2) 

CE3119A 

CE3208A 


CE2102K 
CE2105A..B  (2) 
CE2108A..H  (8) 
CE2115A..B  (2) 
CE2201F..N  (9) 
CE2206A 
CE2401E..F  (2) 
CE2404A..B  (2) 
CE2408A..B  (2) 
CE3102A..C  (3) 
CE3104A..C  (3) 
CE3109A 
CE3112A..D  (4) 
EE3203A 
CE3301A 


CE2102N..Y  (12) 
CE2106A..B  (2) 
CE2109A..C  (3) 
CE2120A..B  (2) 
CE2203A 
CE2208B 
EE2401G 
CE2405B 
CE2409A..B  (2) 
CE3102F..H  (3) 
CE3106A..B  (2) 
CE3110A 
CE3114A..B  (2) 
EE3204A 
EE3301B 
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CE3302A 
CE3402A 
CE3403E..F  (2) 
CE3405C..D  (2) 
CE3409A 
CE3410C..E  (3) 
CE3412A 
CE3602A..D  (4) 
CE3606A..B  (2) 
CE3706D 
CE3806A..B  (2) 
CE3905A..C  (3) 


CE3304A 
EE3402B 
CE3404B..D  (3) 
CE3406A..D  (4) 
CE3409C..E  (3) 
EE3410F 
EE3412C 
CE3603A 
CE3704A..F  (6) 
CE3706F..G  (2) 
CE3806D..E  (2) 
CE3905L 


CE3305A 
CE3402C..D  (2) 
CE3405A 
CE3407A..C  (3) 
EE3409F 
CE3411A 
CE3413A..C(3) 
CE3604A..B  (2) 
CE3704M..O  (3) 
CE3804A..P  (16) 
CE3806G..H  (2) 
CE3906A..C  (3) 


CE3401A 
CE3403A..C  (3) 
EE3405B 
CE3408A..C  (3) 
CE3410A 
CE3411C 
CE3414A 
CE3605A..E  (5) 
CE3705A..E  (5) 
CE3805A..B  (2) 
CE3904A..B  (2) 
CE3906E..F  (2) 


2.3  TEST  MODinCATIONS 

Modifications  (see  section  1.3)  were  required  for  13  tests. 

The  following  test  was  split  into  two  or  more  tests  because  this  implementation  did  not  report  the 
violations  of  the  Ada  Standard  in  the  way  expected  by  the  original  tests. 

B97103E 

C45524A..K  (11  tests)  were  graded  passed  by  Test  Modification  as  directed  by  the  AVO.  These  tests 
expect  that  a  repeated  division  will  result  in  zero;  but  the  Ada  standard  only  requires  that  the  result 
lie  in  the  smallest  safe  interval.  Thus,  the  tests  were  modified  to  check  that  the  result  was  within  the 
smallest  safe  interval,  by  adding  the  following  code  after  line  141;  the  modified  tests  were  passed: 

ELSIF  VAL  <  =  FSAFE_SMALL  THEN  COMMENT  ("UNDERFLOW  SEEMS  GRADUAL"); 

CE3901A  was  graded  passed  by  Test  Modification  as  directed  by  the  AVO.  This  test  expects  that 
implementations  that  do  not  support  external  files  will  raise  USE_ERROR  on  the  attempt  to  create 
a  file  at  line  52;  this  implementation  raises  NAME_ERROR,  as  allowed  by  A1 -00332.  TTje  test  was 
modified  by  inserting  ’  |  NAME_ERROR’  into  the  exception  choice  at  line  52,  and  the  modified  test 
was  passed. 
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CHAPTER  3 

PROCESSING  INFORMATION 
3.1  TESTING  ENVIRONMENT 

The  Ada  implementation  tested  in  this  validation  effort  is  described  adequately  by  the  information 
given  in  the  initial  pages  of  this  report. 

For  a  point  of  contact  for  technical  information  about  this  Ada  implementation  system,  see: 

Tim  Magness 
SD-SdconUK  Ltd 
Pembroke  House 
Pembroke  Broadway 
Camberiey 
Surrey 
GU15  3XD 

For  a  point  of  contact  for  sales  information  about  this  Ada  implementation  system,  see: 

Colin  Foster 
SD-Sckon  UK  Ltd 
Pembroke  House 
Pembroke  Broadway 
Camberiey 
Surrey 
GUIS  3XD 

Testuig  of  this  Ada  implementation  was  conducted  at  the  customer’s  site  by  a  validation  team  from 
the  AVF. 


3.2  SUMMARY  OF  TEST  RESULTS 

An  Ada  Implementation  passes  a  given  ACVC  version  if  it  processes  each  test  of  the  customized  test 
suite  in  accordance  with  the  Ada  Programming  Language  Standard,  whether  the  test  is  applicable  or 
inapplicable;  otherwise,  the  Ada  Implementation  fails  the  ACVC  (Pro90]. 

For  all  processed  tests  (inapplicable  and  applicable),  a  result  was  obtained  that  conforms  to  the  Ada 
Programming  Language  Standard. 


a)  Total  Number  of  Applicable  Tests  3611 

b)  Total  Number  of  Withdrawn  Tests  92 

c)  Processed  Inapplicable  Tests  467 

d)  Non-Processed  I/O  Tests  0 


e)  Non-Processed  Floating-Point  Precision  Tests  0 


ValldaUon  Somiimy  Report 


AVF_VSR_9OS0aa3 


SD-Sclron  UK  Limited 


Chapter  3  -  Page  1  of  2 


XD  Ada  MC6S00  Version  1.2 


PROCESSING  INFORMATION 


f)  Total  Number  of  Inapplicable  Tests  467  (c+d+e) 

g)  TotalNumberofTestsforACVCl.il  4170  (a+b+f) 


3.3  TEST  EXECUTION 

Version  1.11  of  the  ACVC  comprises  4170  tests.  When  this  compiler  was  tested,  the  tests  listed  in 
section  2.1  had  been  withdrawn  because  of  test  errors.  The  AVF  determined  that  467  tests  were 
inapplicable  to  this  implementation.  All  inapplicable  tests  were  processed  during  validation  testing. 
In  addition,  the  modified  tests  mentioned  in  section  2.3  were  also  processed. 

A  magnetic  tape  containing  the  customized  test  suite  (see  section  1.3)  was  taken  on-site  by  the 
validation  team  for  processing.  The  contents  of  the  magnetic  tape  were  loaded  on  to  a  VAX  8600 
and  then  copied  across  to  the  host  using  DECnet. 

After  the  test  files  were  loaded  onto  the  host  computer,  the  full  set  of  tests  was  processed  by  the  Ada 
implementation. 

The  tests  were  compiled  and  linked  on  the  host  computer  system,  as  appropriate.  The  executable 
images  were  transferred  to  the  target  computer  system  by  the  communications  link  described  above, 
and  run.  The  results  were  captured  on  the  host  computer  system. 

Testing  was  performed  using  command  scripts  provided  by  the  customer  and  reviewed  by  the 
validation  team.  See  Appendix  B  for  a  complete  listing  of  the  processing  options  for  this 
implementation.  It  also  indicates  the  defoult  options.  The  options  invoked  explicitly  for  validation 
testing  during  this  test  were: 

/LIST  used  for  tests  requiring  compilation  listings 

/DEV=DAY_0  in-house  compiler  option  to  remove  extraneous  listing  information  eg  dates 

and  headers. 

Test  output,  compiler  and  linker  listings,  and  job  logs  were  captured  on  magnetic  tape  and  archived 
at  the  AVF.  The  listings  examined  on-site  by  the  validation  team  were  also  archived. 
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Predefined  Language  Pragmas 


In  addition  to  the  standard  predefined  pragmas,  described  in  Annex  B 
of  the  Reference  Manual  for  the  Ada  Programming  Language,  XD  Ada  sup¬ 
ports  pragmas  CALL.SEQUENCE.FUNCTION,  CALL.SEQUENC^ 
PROCEDURE,  LINK_OPnON,  and  TITLE,  which  are  defined  here. 
This  annex  also  summarizes  the  definitions  given  elsewhere  of  the 
remaining  implementation-defined  pragmas. 

Definitions 

CALL  SEQUENCE.FUNCnON 
CALL_SEQUENCE_PROCEDURE 

The  pragma  CALL_SEQUENCE_ PROCEDURE  is  used  for  describing 
machine  code  iiuertions  or  exported  subprograms.  It  specifies  how 
parameters  are  mapped  onto  registers,  and  which  registers  must  be 
preserved,  for  machine  code  insertions  (see  Section  13.8).  The  pragma 
CALL_SEQUENCE_FUNCnON  is  also  provided.  These  pragmas  have 
the  form: 

pra«M  CALL_SeQUeNCB_njNCTION 

<(  (UNIT  «>|  lnternal_naine 
(,  (RESULT_TYPE  ->]  typ«_m«rk  ) 

(,  ( PARAMETER_TYPES  ->)  T  pBraraeter_type8  )  ) 

(,  [MECHANISm”->)  mechanism  ) 

(  ,  (RESOLT_MECHANISM  ->  ]  mechaniBm_8pec  ) 

(,  (PRESERVED_REGISTERS  ->  )  (  registers  )  ) 

) ; 

pragaa  CALL_SEOUENCE_PROCEDURB 

((  (UNIT  •>)  internal_name 
(,  ( PARAI1ETER_TYPES  -> )  (  parameter_types  )  | 

(,  (MECHANISM*->)  mechanism  ) 

(,  [ PRBSERVBD_REGISTERS  ->  )  (  registers  )  ) 

)  ; 
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parameter^types 

null  I  type^mark  {,  type^mark} 
mechanism  t:* 

mechanism^spec  |  (  mechanism^^spec  {,  mechanism^spec)  ) 
mechaniem^epec  !j= 

mechaniam^najne  [  (  (REGISTER  ->  ]  register^name  )  ) 

mechaniam^name  i:» 
value"  I 

REFERENCE  j  BIT_REFERENCE  | 

DOPE^VECTOR  j  BIT_DOPE_VECTOR 

registers  tt* 

auii  I  register^name  register^name  ) 

Functions  must  be  identified  by  their  internal  names  and  parameter 
and  result  types.  The  parameter  and  result  types  can  be  onrutted  only  if 
there  is  exactly  one  function  of  that  name  in  the  same  declarative  part  or 
package  specification.  Otherwise,  both  the  parameter  and  result  types 
must  be  specified. 

Procedures  must  be  identified  by  their  internal  names  and  parameter 
types.  The  parameter  types  can  be  onutted  only  if  there  is  exactly 
one  procedure  of  that  name  in  the  same  declarative  part  or  package 
specification.  Otherwise,  the  parameter  types  must  be  specified. 

The  parameter  types  option  specifies  a  series  of  one  or  more  type 
marks  (type  or  subtype  names),  not  parameter  names.  Each  type  mark 
is  positionally  associated  with  a  formal  parameter  in  the  subprogram's 
declaration.  The  absence  of  parameters  must  be  indicated  by  the 
reserved  word  null. 

The  result  type  option  is  used  only  for  functions;  it  specifies  the  type  or 
subtype  of  the  function  result. 

The  mechanism  option  specifies  how  the  imported  subprogram  expects 
its  parameters  to  be  passed  (for  example,  by  value,  by  reference  or 
by  descriptor).  The  calling  program  (namely  the  XD  Ada  program) 
is  responsible  for  ensuring  that  parameters  are  passed  in  the  form 
required  by  the  external  routine. 

If  the  first  form  of  the  mechanism  option  is  given  (a  single  mechanism 
name  without  parentheses),  all  parameters  are  passed  using  that  mech¬ 
anism.  If  the  second  form  is  given  (a  series  of  mechanism  names  in 
parentheses  and  separated  by  commas),  each  mechanism  name  de¬ 
termines  how  the  f»rameter  in  the  same  position  in  the  subprogram 
specification  will  be  passed.  With  the  second  form,  each  parameter 
name  must  have  an  associated  mechanism  name. 
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The  result  mechanism  option  is  used  only  for  functions;  it  specifies  the 
parameter-passing  mechanism  for  passing  the  result  type. 

Mechanism  names  are  described  in  Section  13. 9a. 1.1. 

The  preserved  registers  option  gives  a  list  of  hardware  registers  which 
are  not  altered  by  the  procedure  or  function.  If  this  option  is  omitted  it 
implies  that  no  registers  are  preserved;  in  this  case  the  effect  is  one  of 
the  following; 

•  If  the  body  of  the  subprogram  is  written  in  Ada,  the  compilpr 
calculates  which  registers  are  preserved 

•  If  the  body  of  the  subprogram  is  a  machine  code  insertion,  the 
pragma  has  the  same  effect  as  pragma  lMPORT_PROCEDURE 


UNK.OPTION 

This  pragma  is  used  to  associate  link  option  file  luunes  with  a  program. 
Link  option  hies  are  used  to  specify  the  target  and  mapping  defuutioiu 
to  be  used  when  building  the  program.  In  this  way,  they  do  not  have 
to  be  explicitly  defined  on  the  XDACS  LINK  command  line.  The 
appropriate  external  target  and  mapping  definitions  (in  the  form  of  link 
option  files)  are  entered  into  the  program  library  by  use  of  the  XDACS 
command  COPY  LINK_OPTION/FORElGN,  as  described  in  Developing 
XD  Ada  Programs  on  VMS  Systems  for  the  MC68020.  If  a  suitable  link 
option  file  exists  in  another  program  library,  it  can  be  copied  to  the 
current  program  library  with  the  XDACS  command  COPY  LINK_ 
OPTION.  The  advantage  of  using  link  option  files  is  that  the  program 
definition  is  separate  from  the  program  itself,  and  so  can  be  altered 
without  making  the  last  compile  obsolete.  The  UNK.OPTION  pragma 
therefore  removes  the  need  to  recompile  the  whole  program.  More 
detail  on  this  topic  can  be  found  in  Sections  7.9  and  8.10  of  Developing 
XD  Ada  Programs  on  VMS  Systems  for  the  MC68020. 

Pragma  UNK.OPTION  has  the  form: 

pra«aa  lINK_OPTION<  ( 

(  (TARGBT“>)link-option-file-najne) 

I ,  (KAPPIMG->)llnK-optlon-flle-naJoe) 

Ilf 

This  pragma  is  only  allowed  in  the  outermost  declarative  part  of  a 
subprogram  that  is  a  library  unit;  at  most  one  such  pragma  is  allowed 
in  a  subprogram.  If  it  occurs  in  a  subprogram  other  than  the  main 
program,  tlus  pragma  has  no  effect  (see  Sections  9.8  and  9.9  (LRM)). 


Predefined  Language  Pragmas  B-3 


TITLE 


Takes  a  title  or  a  subtitle  string,  or  both,  in  either  order,  as  arguments. 

Pragma  TITLE  has  the  form: 

pragma  TITLE  (titling-option 
[ .titling-option) ) ; 

titling-option  i« 

(TITLE  ->)  Btring_literal 
I  [SUBTITLE  ->)  atrlng_literal 

This  pragma  is  allowed  anywhere  a  pragma  is  allowed;  the  given  strings 

supersede  the  default  title  or  subtitle  portions  of  a  compilation  listing. 

Summary 

Pragma  Meaning 

EXP0RT_EXCEPT10N  Takes  an  internal  name  denoting  an 

exception,  and  optionally  takes  an 
external  designator  (the  name  of  an 
XD  Ada  Builder  global  symbol),  and 
a  form  (ADA)  as  arguments.  Ihis 
pragma  is  only  allowed  at  the  place 
of  a  declarative  item,  and  must  apply 
to  an  exception  declared  by  an  earlier 
declarative  item  of  the  same  declara¬ 
tive  part  or  package  specification.  The 

Eragma  permits  an  Ada  exception  to 
e  handled  by  programs  written  in  XD 
Ada  MC68020  assembly  language  (see 
Section  13.9a.3.2). 

EXPORT.FUNCnON  Takes  an  internal  name  denoting  a 

function,  and  optionally  takes  an  ex¬ 
ternal  designator  (the  name  of  an  XD 
Ada  Builder  global  symbol),  parameter 
types,  and  result  type  as  arguments. 

This  pragma  is  only  allowed  at  the  place 
of  a  declarative  item,  and  must  apply 
to  a  function  declared  by  an  earlier 
declarative  item  of  the  same  declara¬ 
tive  part  or  package  specification.  In 
the  case  of  a  function  declared  as  a 
compilation  unit,  the  pragma  is  only 
allowed  after  the  function  declaration 
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EXPORT.OBJECT 


EXPORT.PRCX^DURE 


and  before  any  subsequent  compilation 
unit.  This  pragma  is  not  allowed  for  a 
function  declared  with  a  renaming  dec¬ 
laration,  and  is  not  allowed  for  a  generic 
function  (it  can  be  given  for  a  generic 
instantiation).  This  pragma  permits  cm 
Ada  function  to  be  called  from  a  pro¬ 
gram  written  in  assembly  language  (see 
Section  13.9a.  1.2). 

Takes  an  internal  name  denoting  an 
object,  and  optionally  takes  an  exter¬ 
nal  designator  (the  name  of  an  XD  Ada 
Builder  global  symbol),  and  size  des¬ 
ignator  as  arguments.  This  pragma  is 
only  allowed  at  the  place  of  a  declarative 
item  at  the  outermost  level  of  a  library 
package  specification  or  body,  and  must 
apply  to  a  variable  declared  by  an  earlier 
declarative  item  of  the  same  package 
specification  or  body;  the  variable  must 
be  of  a  type  or  subtype  that  has  a  con¬ 
stant  size  at  compile  time.  This  pragma 
is  not  allowed  for  objects  declar^  with  a 
renaming  declaration,  and  is  not  allowed 
in  a  generic  unit.  This  pragma  permits 
an  Ada  object  to  be  referred  to  by  a 
routine  written  in  assembly  language  (see 
Section  13.9a.2.2). 

Takes  an  internal  name  denoting  a  pro¬ 
cedure,  and  optionally  takes  an  external 
desigiuitor  (the  lume  of  an  XD  Ada 
Builder  global  symbol),  and  parameter 
types  as  arguments,  lliis  pragma  is  only 
allowed  at  the  place  of  a  declarative  item, 
and  must  apply  to  a  procedure  declared 
by  an  earlier  declarative  item  of  the  same 
declarative  part  or  package  specification. 
In  the  case  of  a  procedure  declared  as 
a  compilation  unit,  the  pragma  is  only 
allowed  after  the  procedure  declaration 
and  before  any  subsequent  compilation 
unit.  This  pragma  is  not  allowed  for 
a  procedure  declared  with  a  renaming 
declaration,  and  is  not  allowed  for  a 
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generic  procedure  (it  may  be  given  for 
a  generic  instantiation).  This  pragma 
permits  an  Ada  routine  to  be  called  from 
a  program  written  in  assembly  language 
(see  Section  13.9a. 1.2). 

IMPORT_EXCEPTION  Takes  an  internal  name  denoting  an 

exception,  and  optionally  takes  an  ex¬ 
ternal  designator  (the  name  of  an  XD 
Ada  Builder  global  symbol),  and  a  form 
(ADA)  as  arguments.  This  pragma  is 
only  allowed  at  the  place  of  a  declarative 
item,  and  must  apply  to  an  exception 
declared  by  an  earlier  declarative  item 
of  the  same  declarative  part  or  package 
specification.  The  pragma  is  included  for 
compatibility  with  VAX  Ada  (see  Section 
13.9a.3.1). 

IMPORT.FUNCnON  Takes  an  internal  name  denoting  a  func¬ 

tion,  and  optionally  takes  an  external 
designator  (the  name  of  an  XD  Ada 
Builder  glo^l  symbol),  parameter  types, 
and  result  type  as  arguments.  Pragma 
INTERFACE  must  be  used  with  this 
pragma  (see  Section  13.9).  This  pragma 
is  only  allowed  at  the  place  of  a  dedax- 
ative  item,  and  must  apply  to  a  function 
declared  by  an  earlier  declarative  item 
of  the  same  declarative  part  or  package 
specification.  In  the  case  of  a  fimc- 
tion  declared  as  a  compilation  unit,  the 
pragma  is  only  allowed  after  the  function 
declaration  and  before  any  subsequent 
compilation  unit.  This  pragma  is  allowed 
for  a  function  declared  with  a  renaming 
declaration;  it  is  not  allowed  for  a  generic 
function  or  a  generic  function  instantia¬ 
tion.  This  pragnna  permits  an  assembly 
language  routine  to  be  used  as  an  Ada 
function  (see  Section  13. 9a. 1.1). 


B-6  Pradafined  Language  Pragmas 


IMPORT.OBJECT 


IMPORT.PROCEDURE 


Takes  an  internal  name  denoting  an 
object,  and  optionally  takes  an  external 
designator  (the  name  of  an  XD  Ada 
Builder  global  symbol),  as  arguments. 
This  pragma  is  only  allowed  at  the  place 
of  a  declarative  item  at  the  outermost 
level  of  a  library  package  specification 
or  body,  and  must  apply  to  a  variable 
declared  by  an  earlier  declarative  item  of 
the  same  package  specification  or  body; 
the  variable  must  be  of  a  type  or  subtype 
that  has  a  constant  size  at  compile  time. 
This  pragma  is  not  allowed  for  objects 
declared  with  a  renaming  declaration, 
and  is  not  allowed  in  a  generic  unit.  This 
pragma  permits  storage  declared  in  an 
assembly  language  routine  to  be  referred 
to  by  an  Ada  program  (see  Section 
13.9a.2.1). 

Takes  an  internal  name  denoting  a 
procedure,  and  optionally  takes  an  ex¬ 
ternal  designator  (the  name  of  an  XD 
Ada  Builder  global  symbol),  and  pa¬ 
rameter  types  as  arguments.  Pragma 
INTERFACE  must  be  used  with  this 
pragma  (see  Section  13.9).  This  pragma 
is  only  allowed  at  the  place  of  a  declara¬ 
tive  item,  and  must  apply  to  a  procedure 
declared  by  an  earlier  declarative  item 
of  the  same  declarative  part  or  pack¬ 
age  specification.  In  the  case  of  a 
procedure  declared  as  a  compilation 
unit,  the  pragma  is  only  allowed  after 
the  procedure  declaration  and  before 
any  subsequent  compilation  unit.  This 
pragma  is  allowed  for  a  procedure  de¬ 
clared  with  a  renaming  declaration;  it  is 
not  allowed  for  a  generic  procedure  or 
a  generic  procedure  instantiation.  This 
pragma  permits  an  assembly  language 
routine  to  be  used  as  an  Ada  procedure 
(see  Section  13.9a.  1.1). 
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INTERFACE 

LEVEL 

STORAGE.UNTT 

SLTPPRESS.ALL 

VOLATILE 


In  XD  Ada,  pragma  INTERFACE  is 
required  in  combination  with  pragmas 
IMPORT.FUNCTION  and  IMPORT 
PROCEDURE  (see  Section  13.9a.l).  ~ 

This  pragma  idenhfies  a  task  or  task  type 
as  rurtning  at  interrupt  level.  Pragma 
LEVEL  has  one  argument  specifying 
the  level  for  its  interrupts  (see  Section 
13.5.1). 

In  XD  Ada,  the  only  argument  allowed 
for  this  pragma  is  8. 

This  pragma  has  no  argument  and  is 
only  allowed  following  a  compilation 
unit.  This  pragma  specifies  that  all  run¬ 
time  checks  in  the  unit  are  suppressed 
(see  Section  11.7). 

Takes  the  simple  name  of  a  variable 
as  the  single  argument.  This  pragma 
is  only  allowed  for  a  variable  declared 
by  an  object  declaration.  The  variable 
declarabon  and  the  pragma  must  both 
occur  (in  this  order)  immediately  within 
the  same  declarative  part  or  package 
specification.  The  pragma  must  appear 
before  any  occurrence  of  the  name  of 
the  variable  other  than  in  an  address 
clause  or  in  one  of  the  XD  Ada  pragmas 
IMPORT.OBJECT  or  EXPORT.OBJECT. 
The  variable  cannot  be  declared  by  a 
renaming  declaration.  The  VOLATILE 
pragma  specifies  that  the  variable  may  be 
modified  asynchronously.  This  pragma 
instructs  the  compiler  to  obtain  the  value 
of  a  variable  from  memory  each  time  it 
is  used  (see  Section  9,11). 
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This  chapter  supplies  details  of  three  pragmas  introduced  by  XD  Ada 
MC68020  Version  1.2,  pragma  DIRECT. INTERRUPT_ENTRY,  pragma 
IDENT  and  pragma  TIME.SLICE.  XD  Ada  pragmas  in  addition  to  those 
defined  in  Aimex  B  of  the  Reference  Manual  for  the  AdaProgramming 
Unguage  (CALL  SEQUENCE  FUNCTION,  CALL.SEQUENCE. 
PROCEDURE,  LEVEL,  UNK.OPTION  and  TITLE)  are  described  in 
the  XD  Ada  MC6S020  Supplement  to  the  Ada  Language  Reference  Mamud  for 
Version  1.0. 

OcfinHiona 

IDENT 

Takes  a  string  literal  of  31  or  fewer  characters  as  the  single  argument. 
The  pragma  IDENT  has  the  following  form: 

tOBHT  (•trlng.Xlteral ) ; 

This  pragma  is  allowed  only  in  the  outermost  decbrative  part  of  a 
compilation  unit.  The  given  string  is  used  to  identify  the  object  module 
associated  with  the  compilation  unit  in  which  the  pragma  IDENT  occurs. 

Summary 

Pragma  Meaning 

DIRECT.INTERPUPT.ENTRY  Takes  the  simple  name  of  an  interrupt 

entry,  which  must  have  no  parameters, 
as  the  single  argument.  This  pragma 
signals  to  the  compiler  that  the  interrupt 
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entry  is  to  be  directly  connected  to  the 
hardware  interrupt  (see  Section  13.5.1). 

Takes  a  static  expression  of  the  prede¬ 
fined  fixed  point  type  DURATION  (in 
Package  STANDARD)  as  the  single  ar- 
^ment.  This  pragma  is  only  allowed 
in  the  outermost  declarative  part  of  a 
library  subprogram,  and  at  most  one 
such  pragma  is  allowed  in  a  library  sub¬ 
program.  It  has  an  effect  only  when 
the  subprogram  to  which  it  applies  is 
used  as  a  main  program.  This  pragma 
specifies  the  nominal  amount  of  elapsed 
time  permitted  for  the  execution  of  a  task 
when  other  tasks  of  the  same  priority  are 
also  eligible  for  execution.  A  positive, 
nonzero  value  of  the  static  expression 
enables  scheduling  for  all  tasks  in  the 
subprogram;  a  negative  or  zero  value 
disables  it  (see  Section  9.8a). 
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NOTE 

The  complete  Appendix  C  (specification  of  the  package 
STANDARD)  is  reproduced  for  convenience.  The  XD  Ada 
additions  to  this  package  are  the  types  SHORT. INTEGER, 

SHORT  SHORT  INTEGER,  LONG.FLOAT,  and  LONG 
LONG.FLOAT. 

'  This  appendix  outlines  the  specification  of  the  package  STANDARD 

containing  all  predefined  identifiers  in  the  language.  The  corresponding 
package  body  is  implementation-defined  and  is  not  shown. 

:  The  operators  that  are  predefined  for  the  types  declared  in  the  package 

STANDARD  are  given  in  comments  since  they  are  implicitly  declared. 
Italics  are  used  for  pseudo-names  of  anonymous  types  (such  as  umver- 
saijtal)  and  for  undefined  information  (such  as  implementationjiefined 
and  anyJLxed_pointJype). 

3  p«ek«««  STANDARD  la 

4  type  BOOLEAN  la  (FALSE,  TRUE); 

—  Tha  predetinad  relational  oparatora  for  thia  type  are  as  followsi 


--  fuaetioa 

I  LEFT, 

RIGHT 

BCX^LEAN) 

r«turD 

BOOLEAN ; 

—  fuactlOB 

(LEFT, 

RIGHT 

BOOLEAN) 

r«turs 

BOOLEAN; 

—  (uacttoa 

-<- 

(LEFT, 

RIGHT 

BOOLEAN) 

r«turD 

BOOLEAN; 

—  (uaetlea 

( LEFT, 

RIGHT 

BOOLEAN) 

r«turv 

BOOLEAN; 

--  fUBCtlOB 

•>** 

(LEFT, 

RIGHT 

BOOLEAN) 

rvturs 

BOOLEAN; 

--  fUBCtlOB 

(  LEFT, 

RIGHT 

BOOLEAN) 

r«turB 

BOOLEAN; 
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--  The  predefined  logical  operators  and  the  predefined  logical 

—  negation  operator  are  as  follows: 

—  fuactiOB  "and  (LEFT,  RIGHT  :  BOOLEAN)  return  BOOLEAN; 

—  function  "or"  (LEFT,  RIGHT  :  BOOLEAN)  return  BOOLEAN; 

--  function  -xor-  (LEFT,  RIGHT  :  BOOLEAN)  return  BOOLEAN; 

--  function  "not*  (RIGHT  :  BOOLEAN)  return  BOOLEAN; 

s  --  The  universal  type  univer3al_integer  is  predefined. 

6  type  INTEGER  ie  impleaenCation_def ined: 

—  The  predefined  operators  for  this  type  are  as  follows: 

—  function  (LEFT,  RIGHT  :  INTEGER)  return  B(X)LEAN; 

—  function  -/-■  (LEFT,  RIGHT  :  INTEGER)  return  BOOLEAN; 

--  function  ■<■  (LEFT,  RIGHT  :  INTEGER)  return  BOOLEAN; 

--  function  ■<--  (LEFT,  RIGHT  :  INTEGER)  return  BOOLEAN; 

—  function  ->-  (LEFT,  RIGHT  :  INTEGER)  return  BOOLEAN; 

—  function  ->-■  (LEFT,  RIGHT  i  INTEGER)  return  BOOLEAN; 

—  function  (RIGHT  :  INTEGER)  return  INTEGER; 

--  function  ■-*  (RIGHT  :  INTEGER)  return  INTEGER; 

—  function  'abs-  (RIGHT  :  INTEGER)  return  INTEGBR; 

—  function  -i’  (LEFT,  RIGHT  :  INTEGER)  return  INTEGER; 

—  function  *-*  (LEFT,  RIGHT  i  INTEGER)  return  INTEGER; 

—  function  -•*  (LEFT,  RIGHT  i  INTEGER)  return  INTEGER; 

—  function  ■/*  (LEFT,  RIGHT  i  INTEGER)  return  INTEGER; 

—  fnnotion  ‘reel*  (LEFT,  RIGHT  t  INTEGER)  return  INTEGER; 

—  function  -mod*  (LEFT,  RIGHT  ;  INTEGER)  return  INTEGER; 

--  function  (LEFT  t  INTEGER; 

RIGHT  :  INTEGER)  return  INTEGER; 

7  --  ,.n  implenentation  may  provide  additional  predefined  integer  types. 

--  :t  is  recomraended  that  the  names  of  such  additional  types  end 
--  with  INTEGER  as  in  SHORT_INTEGER  or  LONG_ I NTEGER .  The  specification 
'-f  each  operator  for  the  type  univer8al_integer,  or  for 

—  any  additional  predefined  integer  type,  is  obtained  by  replacing 
_  INTEGER  by  the  name  of  the  type  in  the  specification  of  the 

—  corresponding  operator  of  the  type  INTEGER,  except  for  the  right 
--  operand  of  the  exponentiating  operator. 

type  SHORT_INTBGBR  In  iBpIeBentation_defined( 
type  short' SHORT. INTEGER  is  lapieaantaCion.definad; 

a  —  The  universal  type  univuratl^caal  is  predefined. 

9  type  FLOAT  is  leplenencacion.defined; 

—  The  predefined  operators  for  this  type  are  as  follows: 

—  fuactien  •-*  (LEFT,  RIGHT  :  FLOAT)  return  BOOLEAN; 

—  function  ■/-•  (LEFT,  RIGHT  i  FLOAT)  return  BOOLEAN; 

--  fuactien  -<*  (LEFT,  RIGHT  :  FLOAT)  return  BOOLEAN) 

--  function  (LEFT,  RIGHT  :  FLOAT)  return  BOOLEAN) 

—  function  ■>'  (LEFT,  RIGHT  :  FLOAT)  return  BOOLEM; 

--  function  (LEFT,  RIGHT  :  FLOAT)  return  BOOLEAN; 

--  function  (RIGHT  :  FLOAT)  return  FLOAT; 

--  function  ---  (RIGHT  :  FLOAT)  return  FLOAT; 

—  function  -abs-  (RIGHT  :  FLOAT)  return  FLOAT; 
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fuaetloa  *'■*-'* 

( LEFT, 

RIGHT  : 

fuaetioa  *'** 

( LEFT, 

RIGHT  : 

fuaetiea 

(LEFT, 

RIGHT  : 

fuaetioa 

( LEFT, 

RIGHT  : 

fuaetloa 

(  LEFT 

:  FLOAT  i 

FLOAT)  ratarn  FLOAT; 

FLOAT )  ratura  FLOAT ; 

FLOAT)  ratura  FLOAT; 

FLOAT)  ratura  FLOAT; 

RIGHT  :  INTEGER)  ratura  FLOAT; 


An  implementation  may  provide  additional  predefined  floating-point 
types.  It  IS  recommended  that  the  names  of  such  additional  types 
end  with  FLOAT  as  in  SHORT_FLOAT  or  LONG_FLCAT.  The  specification 
of  each  operator  for  the  type  univer3al_reMi ,  or  for  any  additional 
predefined  floating-point  type,  is  obtained  by  replacing  FLOAT  by 
the  name  of  the  type  in  the  specification  of  the  corresponding 
operator  of  the  type  FLOAT. 

type  LONG_FLOAT  la  iaple»antation_dofined; 

type  LONG_LONG_ FLOAT  is  iaplemantttion_daij.ned ; 


In  addition,  the  foil :wing  operators  a  e  predefined  for  universal 
types! 

—  (unetioa  ***  (LEFT  t  unxvarBal_intagar; 

RIGHT  t  unXvaraal_raal )  rstnra  univarBal_raal } 

—  lusetiea  "*  (LEFT  i  Ltnivaraal_raal; 

RIGHT  I  univaraal_intagar)  retura  univaraa2_.-aali 

—  fusetiea  */*  (LEFT  :  univaraa2_raal ; 

—  The  type  uniyaraal_/ixad  la  pradallnad.  The  only  operators 

—  declared  for  this  type  are 

—  luaetiea  (LEFT  i  any_tijta<i _point_type! 

RIGHT  t  any_ilxa<i _point_xypa) 
ratara  uni.varaal_txxad; 

—  fuBctlea  ■/”  (LEFT  :  any_fixa<i _point_typa; 

RIGHT  !  tny_tixad _point_typo) 
ratura  u/iivarsai_fijcad; 


The  following  c  sracters  form  the  standard  ASCII  character  sat. 
Characts’-  literals  corresponding  to  control  characters  are  not 
id.r-'tif lers;  they  ara  Indicated  In  italics  in  this  definition. 

type  CHARACTER  is 


r,ji , 

^on  t 

.^CX 

•tx. 

sot , 

anq, 

JCXf 

bai 

bs , 

ht. 

it, 

vt. 

tt, 

cr, 

so, 

Si, 

die. 

del , 

dc2. 

deJ , 

dci , 

nak. 

syn. 

etb 

can. 

on. 

sub. 

esc, 

fSt 

99  > 

rs , 

us , 

t 

'  !  *  f 

«  •  , 

F 

, 

'  i ' , 

,  ,  , 

'  (  '  F 

'  )  '  F 

»  •  F 

'  *  '  F 

' , ' , 

'0*  , 

■  1' , 

■2'  , 

•  3'  , 

'4'  , 

■S'  , 

•S'  , 

'  7  * 

'9'  , 

'  :  »  , 

'  ?  '  F 

*  •'  r 

■  > '  , 

»  j  » 

'A'  , 

'B'  , 

'  ~  '  t 

'  D'  , 

'E'  , 

■  r ' » 

■G' 

'H'  , 

'  I  '  F 

'  J‘  , 

'  X  '  , 

‘  L'  , 

'M'  , 

’'y , 

'0' 

'P'  / 

■Q' , 

'  R'  , 

'S'  , 

•  T-  ^ 

'U'  , 

'  W' 

'X'  , 

'Y'  , 

'  Z'  , 

'  f  '  F 
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'a',  ' c  ,  'd',  'e',  '  t'  f  '9'. 

'h',  '  i’  ,  ’'*»  ’  I  '1'#  'm',  '  ri‘  ,  'O'  , 

‘P‘,  ' I  ’ - ' f  's' ,  ' t' ,  ' u ' /  ' V ' ,  ■ w  * , 

■X’,  ••/',  -z',  ■{',  ’I'.  deli; 

for  CHARACTER  ttso  —  128  ASCII  character  set  without  holes 

(0,  1,  2,  5,  4,  5,  125,  126,  127); 

It  —  The  preoefined  operators  for  the  type  CHARACTER  are  the  same 

—  as  for  any  enumeration  type. 

15  package  ASCII  is 


Control 
NUL  : 

characters t 
cosateat  CHARACTER 

nui ; 

SOH  : 

coastaat 

CHARACTER 

aoh ! 

STX  : 

eeaataak 

CHARACTER 

sex; 

ETX  : 

ceaakaak 

CHARACTER 

eex; 

EOT  : 

eoaataat 

CHARACTER 

act; 

ENQ 

eeaakaat 

CHARACTER 

anq; 

ACK  : 

eoBataat 

CHARACTER 

McJc; 

BEL  : 

ceaataat 

CHARACTER 

bai ; 

BS  : 

eoaataat 

CHARACTER 

ba ; 

HT  ; 

coaataat 

CHARACTER 

be; 

LF  1 

eoaakaak 

CHARACTER 

If; 

VT  t 

eoaakaat 

CHARACTER 

vt; 

FF  ! 

coaataat 

CHARACTER 

ff; 

CR  1 

ceaataat 

CHARACTER 

cr; 

SO  ! 

ceaataat 

CHARACTER 

so; 

SI  : 

coaataat 

CHARACTER 

al ; 

DLE  : 

ceaataat 

CHARACTER 

dia; 

OCl  : 

coaataat 

CHARACTER 

del ; 

DC2  : 

ceaataat 

CHARACTER 

dc2 ; 

DC3  : 

coaataat 

CHARACTER 

deJ; 

0C4  : 

coaataat 

CHARACTER 

dc4; 

NAK  1 

coaataat 

CHARACTER 

naJc; 

SYN  1 

ceaataat 

CHARACTER 

ayn; 

ETB  ! 

coaataat 

CHARACTER 

acb; 

CAN  s 

coaataat 

CHARACTER 

can; 

EM  1 

coaataat 

CHARACTER 

aa; 

SUB 

ceaataat 

CHARACTER 

aub; 

ESC 

ceaataat 

CHARACTER 

aac; 

PS 

ceaataat 

CHARACTER 

/a; 

GS 

ceaataat 

CHARACTER 

qa; 

RS 

ceaataat 

CHARACTER 

rs ; 

US 

ceaataat 

CHARACTER 

ua ; 

DEL 

ceaataat 

CHARACTER 

:  - 

del ; 
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—  Other  characters: 


EXCLAM 

coastsat 

CHARACTER 

'  t  ' 

QUOTATION 

coastaat 

CHARACTER 

'  -  ' 

SHARP 

coastsat 

CHARACTER 

'  «  ' 

DOLLAR 

coastsat 

CHARACTER 

'S' 

PERCENT 

coastaat 

CHARACTER 

AMPERSAND 

coastaat 

CHARACTER 

COLON 

coastaat 

CHARACTER 

SEMICOLON 

coastaat 

CHARACTER 

QUERY 

coastaat 

CHARACTER 

'  ?  ' 

AT_SIGN 

coastaat 

CHARACTER 

L_iRACKET 

coastaat 

CHARACTER 

eACK_SLASH 

coastaat 

CHARACTER 

R_ BRACKET 

coastaat 

CHARACTER 

CIRCUMFLEX 

coastaat 

CHARACTER 

'  ' 

UNDERLINE 

coastaat 

CHARACTER 

QHAVE 

coastaat 

CHARACTER 

L_BRACE 

coastaat 

CHARACTER 

coastaat 

CHARACTER 

'1' 

R_BRACE 

coastaat 

CHARACTER 

TILDE 

coastaat 

CHARACTER 

.  - » 

—  Lower  case  letters: 

LC_A  :  ceasteat  CHARACTER  :-  'a'; 


LC_Z  I  eeaataat  CHARACTER  ’  z’ ; 
sad  aIcII; 

—  Predefined  subtypes: 

subtype  NATURAL  is  INTEGER  raaga  0  ..  INTEGER 'LAST; 
subtype  POSITIVE  is  INTEGER  raage  1  ..  INTEGER' LAST; 

—  Predefined  string  type: 

type  STRING  is  array( POSITIVE  raage  <>)  of  CHARACTER; 
pragma  PACK( STRING) ; 


—  The  predefined  operators  for  this  type  are  as  follows: 

—  fuaetiea  *•■  (LEFT,  RIGHT  :  STRING)  retara  BOOLEAN; 

—  fuaetiea  */•’  (LEFT,  RIGHT  :  STRING)  return  BOOLEAN; 

—  fuaetiea  ■<*  (LEFT,  RIGHT  :  STRING)  returs  BOOLEAN; 

—  fuaetiea  -<-■  (LEFT,  RIGHT  ;  STRING)  returs  BOOLEAN; 

—  fuaetiea  *>*  (LEFT,  RIGHT  :  STRING)  returs  BOOLEAN; 

—  fuaetiea  ■>•’  (LEFT,  RIGHT  :  STRING)  returs  BOOLEAN; 


function 

•f 

(LEFT 

STRING; 

RIGHT 

STRING) 

retura 

STRING 

--  function 

-i- 

(LEFT 

CHARACTER; 

RIGHT 

STRING) 

retura 

STRING 

function 

-4- 

(LEFT 

STRING; 

RIGHT 

CHARACTER ) 

returs 

STRING 

function 

(LEFT 

CHARACTER; 

RIGHT 

CHARACTER) 

rotura 

STRING 
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typ«  DURATION  ia  dalta  implem0nt»cion_clefined 
rang*  i/iipieaancaC2on_dsTjtned ; 

—  The  predefined  operators  for  the  type  DURATION  are  the  same  as  for 

—  any  fixed-point  type. 


—  The  predefined  exceptions: 


CONSTRAI NT_ERROR 
fnjMERIC_ERROR 

program”error 

storagb”error 

tasking”error 

aad  STANDARD; 


aaceptloa; 

exception; 

oxeeptlea; 

exeeptlea; 

oxeeptlea; 


Certain  aspects  of  the  predefined  entities  cannot  be  completely  de¬ 
scribed  in  the  language  itself.  For  example,  although  the  enumeration 
type  BOOLEAN  can  be  written  showing  the  two  enumeration  literals 
FALSE  and  TRUE,  the  short-circuit  control  forms  caimot  be  expressed 
in  the  language. 


Note: 

The  language  definition  predefines  the  following  library  units: 


The  package  CALENDAR 

(see  9.6) 

The  package  SYSTEM 

(see  13.7) 

The  package  MACHINE.CODE 

(see  13.8) 

The  generic  procedure  UNCHECKED. 
DEALLOCATION 

(see  13.10.1) 

The  generic  function  UNCHECKED.CONVERSION 

(see  13.10.2) 

The  generic  package  SEQUENTIAL.IO 

(see  14.2.3) 

The  generic  package  DIRECT.IO 

(see  14.2.5) 

The  package  TEXT.IO 

(see  14.3.10) 

The  package  lO.EXCEPTlONS 

(see  14.5) 

The  package  LOW.LEVEL.IO 

(see  14.6) 
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MACRO  PARAMETERS 


This  appendix  contains  the  macro  parameters  used  for  customizing  the  ACVC.  The  meaning  and 
purpose  of  these  parameters  are  explained  in  (UG89].  The  parameter  values  are  presented  in  two 
tables.  The  first  table  lists  the  valued  that  are  defin^  in  terms  of  the  maximum  input-line  length, 
which  is  the  value  for  $MAX_rN-LEN“also  listed  here.  These  values  are  express^  here  as  Ada 
string  aggregates,  where  "V"  represents  the  maximum  input-line  length. 


Macro  Parameter 

$MAX_IN_LEN 

$BIG_ID1 

$BIG_ID2 

$BIG_ID3 

$BIG_ID4 

$BIG_INT_LIT 

$BIG_REAL_LIT 

$BIG_STRING1 

$BIG_STRING2 

$BIANKS 


Macro  Value 


255 

(1..V-1  =>  ’A’,  V  =  >  ’!’) 

(1..V-1  =>  ’A’.  V  =  >  7’) 

(1..V/2  =>  ’A’)  &  ’3’  &  (1..V-1-V/2  =>  ’A’) 
(1..V/2  =>  ’A’)  &  ’4’  &  (1..V-1-V/2  =>  ’A’) 
(1..V-3  =>  ’O’)  &  "298" 

(1..V-5  =>  ’O’)  &  "690.0" 

’"’  &  (1..V/2  =>  ’A’)  &  ’"’ 

’"’  &  (1..V-1-V/2  =>  ’A’) 


(1..V-20  =>  ”) 


$MAX_LEN_INT_BASED_LITERAL  "2:"  &  (1..V-5  =>  ’O’)  &  "11:" 

$MAX_LEN_REAL_BASED_LITERAL  "16:"  &  (1..V-7  =>  ’O’)  &  T.E:" 
$MAX_STRING_LrTERAL  ’"’  &  (1..V-2  =>  A’)  &  ’"’ 


ValklaUon  Snmmarr  Report 


AVF_VSR_90502/73 


SD-Sckoo  UK  Umlted 
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MACRO  PARAMETERS 

The  following  table  lists  all  of  the  other  macro  parameters  and  their  respective  values. 
Macro  Parameter  Macro  Value 


$ACC_SIZE 

SALIGNMENT 

$COUNT_LAST 

$DEFAULT_MEM_SIZE 

$DEFAULT_STOR_UNIT 

$DEFAULT_SYS_NAME 

$DELTA_DOC 

$ENTRY_ADDRESS 

$ENTRY_ADDRESS1 

SENTRY_ADDRESS2 

$FIELD_LAST 

$FTLE_TERMINATOR 

$FIXED_NAME 

$FLOAT_NAME 

$FORM_STRING 

$FORM_STRING2 

SGREATER  THAN  DURATION 


32 

1 

2147483647 

16777216 

8 

MC68000 

2#1.#E-31 

SYSTEM.TO_ADDRESS  (16#68#) 
SYSTEM.TO_ADDRESS  (16#6C#) 
SYSTEM.TO_ADDRESS  (16#70#) 

255 
«  * 

NO_SUCH_TYPE 
LONG  LONG  FLOAT 


"CANNOT_RESTRICT_nLE_CAPACmr 

131072.0 


$GREATER_THAN_DURATION_BASE_LAST 

131073,0 


$GREATER_THAN_FLOAT_BASE_LAST  3.40283E+38 
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$G  REATER_THAN_FLOAT_S  AFE_LARGE 

4.255354E+37 

SGREATER  THAN  SHORT  FLOAT  SAFE  LARGE 


$HlGH_PRIORITY 

$ILLEGAL_EXTERNAL_nLE_NAMEl 

$ILLEGAL_EXTERNAL_FILE_NAME2 

$INAPPROPRlATE_LrNE_LENGTH 

$INAPPROPRIATE_PAGE_LENGTH 

SINCLUDE_PRAGMA1 

$INCLUDE_PRAGMA2 

$INTEGER_nRST 

$INTEGER_LAST 

$INTEGER_LAST_PLUS_1 

$INTERFACE_LANGUAGE 

$LESS_THAN_DURATION 

$LESS_THAN_DURATION_BASE_nRST 

$LINE_TERMINATOR 

$LOW_PRIORITY 

$MACHINE_CX)DE_STATEMENT 

$MACHINE_CODE_TYPE 

$MANTISSA_DOC 

$MAX_D1GITS 

$MAX_INT 

$MAX  INT  PLUS  1 


"NO_SUCH_TYPE" 

15 

ILLEGAL_EXTERNAL_nLE_NAME_l 

ILLEGAL_EXTERNAL_nLE_NAME_2 

-1 

-1 

PRAGMA  INCLUDE  ("A28006D1.TST’) 

PRAGMA  INCLUDE  ("B28006D1.TST") 

-2147483648 

2147483647 

2147483648 

ASSEMBLER 

-131072.0 

-131073.0 

i  » 

0 

OPERANDLESS_INST  (OPCODE=>NOP); 
OPERANDLESS_INST 
31 
18 

2147483647 

2147483648 
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$MIN_INT 

$NAME 

$NAME_L1ST 

$N  AME_SPECinCATION  1 

$NAME_SPECmCATION2 

$NAME_SPECIFICATION3 

$NEG_BASED_INT 

$NEW_MEM_SIZE 

$NEW_STOR_UNIT 

$NEW_SYS_NAME 

$PAGE_TERMINATOR 

$RECORD_DEFINmON 

$RECORD_NAME 

$TASK_SIZE 

$TASK_STORAGE_SIZE 

$TICK 

$VARIABLE_ADDRESS 

$VARIABLE_ADDRESS1 

$VARIABLE_ADDRESS2 

$YOUR_PRAGMA 


-2147483648 

SHORT_SHORT_INTEGER 

MC68000 

NO_SUCH_NAME 

NO_SUCH_NAME 

NO_SUCH_NAME 

16#FFFF_FFFF# 

123456 

8 

MC68000 


RECORD  OPCODErOPERANDLESS  OP;  END 
RECORD; 

OPERANDUESS_INST 

32 

2048 

2#1.0#E-13 

SYSTEM.TO_ADDRESS  (16#40C#) 

SYSTEM.TO_ADDRESS  (16#408#) 

SYSTEM.TO_ADDRESS  (16#404#) 

EXPORT  OBJECT 

EXPORT^EXCEPTION 

EXP0RT_FUNCT10N 

EXPORT_PROCEDURE 

IMPORT_OBJECr 

IMPORT  EXCEPTION 

importIfunction 

IMPORT_PROCEDURE 
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APPENDIX  B 

COMPILATION  SYSTEM  OPTIONS 


The  compiler  options  of  this  Ada  implementation,  as  described  in  this  Appendix,  are  provided  by  the 
customer.  Unless  specifically  noted  otherwise,  references  in  this  appendix  are  to  compiler 
documentation  and  not  to  this  report. 
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UNKER  OPTIONS 

The  linker  options  of  this  Ada  implementation,  as  described  in  this  Appendix,  are  provided  by  the 
customer.  Unless  specifically  noted  otherwise,  references  in  this  appendix  are  to  linker 
documentation  and  not  to  this  report. 
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Creates  an  executable  jn\age  file  for  the  specified  units. 


Format 


LINK  unit-name  [file-spec[, . . .]] 
LINK/NOMAIN  unit-name[,...]  file-spec[,...] 


Command  Qualifiers 
/AFTER  » time 
/BATCH_LOG  “  file-spec 
/BRIEF 

/COMMANO(  -  file-spec) 
/[NOIOEBUG 

/ELABORATION  -  file-spec 
/FULL 

/(NOIIMAGE)  -  file-spec) 
/(NO)KEEP 
/(NOjLOG 
/(NOjMAIN 

/[NO)MAP(  -  file-spec) 

/NAME -job-name 

/(NO)NOTIFY 

/OUTPUT  -  file-spec 

/(NO)PRINTER(  -  queue-name) 

/QUEUE  -  queue-name 

/(NO)SELECTIVE 

/SUBMIT 

/WAIT 


Defaults 

/AFTER -TODAY 
See  text. 

See  text. 

See  text. 

/NODEBUG 
See  text. 

See  text. 

/IMAGE 

/KEEP 

/NOLOG 

/MAIN 

/NOMAP 

See  text. 

/NOTIFY 

/OUTPUT  -  SYSSOUTPUT 

/NOPRINTER 

/QUEUE -SYSSBATCH 

/SELECTIVE 

/WAIT 

/WAIT 


Parameter  Qualifiers 

/LIBRARY 

/MAPPING 

/TARGET 


Defaults 
See  text. 
See  text. 
See  text. 
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Prompts 

Unit: 

.File; 


Command  Parameters 

unit-name 

By  default  (or  if  you  specify  the  /MAIN  qualifier): 

•  You  can  specify  only  one  unit,  the  source  code  of  which  must  be 
written  in  XD  Ada. 

•  The  parameter  umt-name  specifies  the  XD  Ada  main  program,  which 
must  be  a  procedure  or  function  with  no  parameters.  If  the  main 
program  is  a  function,  it  must  return  a  value  of  a  discrete  type;  the 
function  value  is  used  as  the  VMS  image  exit  value. 

If  you  specify  the  /NOMAIN  qualifier; 

•  You  can  specify  one  or  more  foreign  units  that  are  to  be  included 
in  the  executable  image.  The  unit  names  may  include  percent  signs 
( % )  and  asterisks  (* )  as  wildcard  characters.  (See  the  VMS  DCL 
Concepts  Manual  for  detailed  information  on  wildcard  characters.) 

•  The  image  transfer  address  comes  from  one  of  the  foreign  files 
specified. 

file-spec 

Specifies  a  list  of  object  files,  object  libraries,  mapping  definition  files, 
and  target  definition  files,  that  are  to  be  used  in  linking  the  program. 
The  default  directory  is  the  current  default  directory,  "nte  default  file 
type  is  .XOB,  unless  the  /LIBRARY,  /MAPPING,  or  /TARGET  qualifier  is 
used.  No  wildcard  characters  are  allowed  in  a  file  specification. 

If  the  file  is  an  object  library,  you  must  use  the  /LIBRARY  qualifier.  The 
default  file  type  is  .XLB. 

If  the  file  is  a  mapping  definition  file,  you  must  use  the  /MAPPING 
qualifier.  The  default  file  type  is  MPD. 

If  the  file  is  a  target  definition  file  you  must  use  the  /TARGET  qualifier. 
The  default  file  type  is  TGD 

If  you  specify  the  /NOMAIN  qualifier,  the  image  transfer  address  comes 
from  one  of  the  files  (not  units)  specified. 
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Description 

The  LINK  command  performs  the  following  steps: 

1.  Runs  the  prebuild  phase  to  generate  an  elaboration  list. 

2.  Checks  if  a  pragma  LINK.OPTION  is  specified  for  the  main  pro¬ 
gram,  a..d  if  specified,  verifies  that  the  designated  link  option  name 
is  available  in  the  current  program  library.  If  available,  the  copied 
link  option  files  in  the  library  corresponding  to  the  link  option  are 
used,  unless  overridden  by  the  /TARGET  or  /MAPPING  qualifiers. 

Note  that,  unlike  the  CHECK  command,  the  pragma  LINK, 
OPTION  association  for  units  other  than  the  main  program  unit 
is  not  checked 

If  no  target  link  option  is  given  tor  the  main  program  unit  or  the 
designated  target  link  option  is  not  found  in  the  library,  and  the 
logical  name  XDADA$TARGET_DEF  is  not  defined,  and  a  /TARGET 
qualifier  is  not  specified  on  the  LINK  command  line,  an  error  is 
issued.  If  no  mapping  link  option  is  given  for  the  main  program  unit 
or  the  designated  mapping  link  option  is  not  found  in  the  library, 
and  the  logical  name  XDADA$MAPPING_DEF  is  not  dehned,  and  a 
/MAPPING  qualifier  is  not  specified  on  the  XDACS  LINK  command 
line,  the  default  mapping  in  the  target  defiiution  file  is  used. 

3.  If  LINK/NOMAIN  is  not  specified,  checks  that  only  one  unit  is 
specified  and  that  it  is  an  XD  Ada  main  program. 

4.  Forms  the  closure  of  the  main  program  (LINK/MAIN)  or  of  the 
specified  units  (UNK/NOMAIN)  and  verifies  that  all  units  in  the 
closure  are  present,  current  and  complete.  If  XDACS  detects  an 
error,  the  operahon  is  terminated  at  the  end  of  the  prebuild  phase. 

5.  Creates  a  DCL  command  file  for  the  builder.  The  command  file  is 
deleted  after  the  LINK  operation  is  completed  or  terminated,  unless 
LINK/COMMAND  is  specified.  If  UNK/COMMAND  is  specified, 
the  command  file  is  retained  for  future  use,  and  the  build  phase  is 
not  carried  out. 

6.  Unless  the  /COMMAND  qualifier  is  specified,  performs  the  build 
phase  css  follows: 

a.  By  default  (UNK/WAIT),  the  conunand  file  generated  in  step 
5  is  executed  in  a  subprocess.  You  must  wait  for  the  build 
operation  to  terminate  before  issuing  another  command.  Note 
that  when  you  specify  the  /WAIT  qualifier  (the  default),  process 
logical  names  are  propagated  to  the  subprocess  generated  to 
execute  the  command  file. 
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b.  If  you  specify  the  /SUBMIT  qualifier,  the  builder  command  file 
IS  submitted  as  a  batch  job. 

7.  If  the  /DEBUG  qualifier  is  included  in  the  command  line  the  debug 
symbol  table  information  is  placed  in  the  .XXE  file. 

8.  Creates  a  loadable  output  file  with  a  default  file  type  of  XXE. 

XDACS  output  originating  before  the  builder  is  invoked  is  reported 
to  your  terminal  by  default,  or  to  a  file  specified  with  the  /OUTPUT 
qualifier.  Diagnostics  are  reported  to  your  terminal,  by  default,  or  to 
a  log  file  if  the  LINK  command  is  executed  in  batch  mode  (XDACS 
UNK/SUBMIT). 

See  Developing  XD  Ada  Programs  on  VMS  Systems  for  the  MC68020  and  the 
XD  Ada  Version  1.2  New  Features  Manual  for  more  information  on  the  XD 
Ada  target-specific  builder  commands. 


Command  Qualifiers 

/AFTER  =  time 

Requests  that  the  batch  job  be  held  until  after  a  specific  time,  when 
the  LINK  command  is  executed  in  batch  mode  (LINK/SUBMIT).  If  the 
specified  time  has  already  passed,  the  job  is  queued  for  imme^te 
processing. 

You  can  specify  either  an  absolute  time  or  a  combination  of  absolute 
and  delta  time.  See  the  VMS  DCL  Concepts  Manual  (or  type  HELP 
Specify  Date-Time  at  the  DCL  prompt)  for  complete  information  on 
specif^ng  time  values. 

/BATCH JLQQ  •  tile-spec 

Provides  a  file  specification  for  the  batch  log  file  when  the  LINK  com¬ 
mand  is  executed  in  batch  mode  (LINK/SUBMIT). 

If  you  do  not  give  a  directory  specification  with  the  file-spec  option,  the 
batch  log  file  is  created  by  default  in  the  current  default  directory.  If 
you  do  not  give  a  file  specification,  the  default  file  name  is  the  job  name 
specified  with  the  /NAME  -  job-name  qualifier.  If  no  job  name  has  been 
specified,  the  program  library  manager  creates  a  file  name  comprising 
up  to  the  first  39  characters  of  the  first  unit  name  specified.  If  you 
specified  LINK/NOMAIN  and  no  job  name  and  there  is  a  wildcard 
character  in  the  first  unit  specified,  the  program  library  manager  uses 
the  default  file  name  XDACS.LINK.  The  default  file  type  is  LOG 
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/BRIEF 

Directs  the  builder  to  produce  a  brief  image  map  hie.  The  /BRIEF 
qualifier  is  valid  only  if  you  also  specify  the  /MAP  qualifier  with  the 
LINK  command.  The  /BRIEF  quallher  is  incompatible  with  the  /FULL 
qualifier. 

A  brief  image  map  hie  contains  only  the  following  sechons: 

•  Object  module  information 

•  Segment  mapping  informahon 

•  Link  run  statistics 

See  also  the  description  of  the  /FULL  qualiher. 

/COMMAND[ = me-spac] 

Controls  whether  the  builder  is  invoked  as  a  result  of  the  LINK  com¬ 
mand,  and  determines  whether  the  command  file  generated  to  invoke 
the  builder  is  saved.  If  you  specify  the  /COMMAND  qualifier,  XDACS 
does  not  invoke  the  builder,  and  the  generated  command  file  is  saved 
for  you  to  invoke  or  submit  as  a  batch  job. 

The  file-spec  option  allows  you  to  enter  a  file  specification  for  the  gen¬ 
erated  command  hie.  The  default  directory  for  the  command  file  is  the 
current  default  directory.  By  default,  XDACS  provides  a  hie  name  com¬ 
prising  up  to  the  first  39  characters  of  the  first  unit  name  specihed.  If 
you  specihed  LINK/NOMAIN  and  you  used  a  wildcard  character  in  the 
first  unit  name  specified,  the  program  library  manager  uses  the  default 
file  name  XDACS_LINK.  The  default  file  type  is  .COM.  No  wildcard 
characters  are  allowed  in  the  file  specihcation. 

By  default,  if  the  /COMMAND  qualiher  is  not  specihed,  XDACS  deletes 
the  generated  command  hie  when  the  LINK  command  completes 
normally  or  is  termiiuited, 

/DEBUG 
INODEBUQ  (D) 

Controls  whether  a  debugger  symbol  table  is  generated  in  the  loadable 
image  file. 

By  default,  no  debugger  symbol  table  is  created. 

/ELABORATION  s  flla-spec 

Provides  a  hie  specification  for  the  object  file  generated  by  the  LINK 
command.  The  file  is  retained  by  XDACS  only  when  the  /COMMAND 
qualifier  is  used:  that  is,  when  the  result  of  tbo  LINK  operation  is  to 
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produce  a  builder  command  file  for  future  use,  rather  than  to  invoke  the 
builder  immediately. 

The  generated  object  file  contains  the  code  that  directs  the  elaboration 
of  library  packages  in  the  closure  of  the  units  specified.  Unless  you  also 
specify  the  /NOMAIN  qualifier,  the  object  file  also  contains  the  image 
transfer  address.  ° 

The  default  directory  for  the  generated  text  file  is  the  current  default 
directory.  The  default  file  tj^e  is  .ELB.  No  wildcard  characters  are 
allowed  in  the  file  specification. 

By  default,  if  you  do  not  specify  the  /ELABORATION  qualifier,  XDACS 
provides  a  file  name  comprising  up  to  the  first  39  characters  of  the  first 
unit  name  specified. 

By  default,  if  you  do  not  specify  the  /COMMAND  qualifier,  XDACS 
deletes  the  generated  object  file  when  the  LINK  command  completes 
normally  or  is  terminated. 

/FULL 

Directs  the  builder  to  produce  a  full  image  map  fUe,  which  is  the  most 
complete  image  map.  The  /FULL  qualifier  is  valid  only  if  you  also 
specify  the  /MAP  qualifier  with  the  LINK  command.  Also,  the  /FULL 
qualifier  is  incompatible  with  the  /BRIEF  qualifier. 

A  full  image  map  file  contains  the  following  sections: 

•  Object  module  information 

•  Segment  mapping  information 

•  Symbol  address  information 

•  Exception  numbers 

•  Link  run  statistics 

/IMAGei^flle-spscJ  (D) 

INOIMAGE 

Controls  whether  the  LINK  command  creates  a  loadable  image  file  and 
optionally  provides  a  file  specification  for  the  file.  The  default  file  type 
is  .XXE.  No  wildcard  characters  are  allowed  in  the  file  specification. 

By  default,  an  executable  image  file  is  created  with  a  file  name  compris¬ 
ing  up  to  the  first  39  characters  of  the  first  unit  name  specitied. 
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/KEEP  (D) 

/NOKEEP 

Controls  whether  the  batch  log  file  generated  is  deleted  after  it 
is  printed  when  the  LINK  command  is  executed  in  batch  mode 
(LINK/SUBMIT). 

By  default,  the  log  file  is  not  deleted. 

/LOG 

/NOLOQ  (D) 

Controls  whether  a  list  of  all  the  units  included  in  the  executable  image 
is  displayed.  The  display  shows  the  units  according  to  the  order  of 
elaboration  for  the  program. 

By  default,  a  list  of  all  the  units  included  in  the  executable  image  is  not 
displayed. 

/MAIN  (D) 

INOMAIN 

Controls  where  the  image  ticmsfer  address  is  to  be  found. 

The  /MAIN  qualifier  indicates  that  the  XD  Ada  unit  specified  deter¬ 
mines  the  image  transfer  address,  and  hence  is  to  be  a  main  program. 

The  /NOMAIN  qualifier  indicates  that  the  image  transfer  address  comes 
from  one  of  the  files  specified,  and  not  from  one  of  the  XD  Ada  units 
specified. 

By  default  (/MAIN),  only  one  XD  Ada  unit  can  be  specified,  and  that 
unit  must  be  an  XD  Ada  main  program. 

/MAPf-m«-spec; 

INOMAP  (D) 

Controls  whether  the  builder  creates  an  image  map  file  and  optionally 
provides  a  file  specification  for  the  file.  The  default  directory  for 
the  image  map  file  is  the  current  directory.  The  default  file  name 
comprises  up  to  the  first  39  characters  of  the  first  urrit  name  specified. 
The  default  file  type  is  .MAP.  No  wildcard  characters  are  allowed  in  the 
file  specification. 

If  neither  the  /BRIEF  nor  the  /FULL  qualifier  is  specified  with  the  /MAP 
qualifier,  /BRIEF  is  assumed. 

By  default,  no  image  map  file  is  created. 
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INAME  =  job-name 

Specifies  a  string  to  be  used  as  the  job  name  and  as  the  file  name  for 
the  batch  log  file  when  the  LINK  command  is  executed  in  batch  mode 
(LINK/SUBMTT).  The  job  name  can  have  from  1  to  39  characters. 

By  default,  if  you  do  not  specify  the  /NAME  qualifier,  XDACS  creates 
a  job  name  comprising  up  to  the  first  39  characters  of  the  first  unit 
name  specified.  If  you  specify  LINK/NOMAIN  but  do  not  specify  the 
/NAME  qualifier,  and  you  use  a  wildcard  character  in  the  first  unit 
name  specified,  the  program  library  manager  uses  the  default  file  name 
XDACS_LINK.  In  these  cases,  the  job  name  is  also  the  file  name  of  the 
batch  log  file. 

/NOT/f  y  (D) 

INONOTIFY 

Controls  whether  a  message  is  broadcast  when  the  LINK  command  is 
executed  in  batch  mode  (UNK/SUBMIT).  The  message  is  broadcast  to 
any  terminal  at  which  you  are  logged  m,  notifying  you  that  your  job  has 
been  completed  or  terminated. 

By  default,  a  message  is  broadcast. 

/OUTPUT  ^nie-spec 

Requests  that  any  output  generated  before  the  builder  is  invoked  be 
written  to  the  file  specified  rather  than  to  SYSSOUTPUT.  Any  diagnostic 
messages  are  written  to  both  SYSSOUTPUT  and  the  file. 

The  default  directory  is  the  current  default  directory.  If  you  specify  a 
file  type  but  omit  the  file  name,  the  default  file  name  is  XDACS.  The 
default  file  type  is  .US.  No  wildcard  characters  are  allowed  in  the  file 
specification. 

By  default,  the  UNK  command  output  is  written  to  SYSSOUTPUT. 

/PRINTERf  »  queue-name] 

/NOPRINTER  (D) 

Controls  whether  the  log  file  is  queued  for  printing  when  the  UNK 
command  is  executed  in  batch  mode  (UNK/SUBMIT)  and  the  batch  job 
is  completed. 

The  /PRINTER  qualifier  allows  you  to  specify  a  particular  print  queue. 
The  default  print  queue  for  the  log  file  is  SYSSPRINT. 

By  default,  the  log  file  is  not  queued  for  printing.  If  you  specify 
/NOPRINTER,  /KEEP  is  assumed. 
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/QUEUE  s  queue-name 

Specifies  the  batch  job  queue  in  which  the  job  is  entered  when  the 
LINK  command  is  executed  in  batch  mode  (LINK/SUBMIT). 

By  default,  if  the  /QUEUE  qualifier  is  not  specified,  the  job  is  placed  in 
the  default  system  batch  job  queue,  SYSSBATCH. 

/SELECTIVE  (D) 

INOSELECTIVE 

Specifies  whether  selective  linking  is  performed. 

Performing  selective  linking  ensures  that  only  subprograms  that  are 
called  will  be  linked  into  the  program  image.  Subprograms  within  the 
closure  of  the  main  program  that  are  not  actually  called  will  be  omitted 
from  the  image  file.  Selective  linking  produces  a  program  image  that 
has  been  optimized  according  to  size. 

Non-selective  linking  eiuures  that  all  defined  subprograms  are  linked 
into  the  image. 

By  default,  selective  iiiUcing  is  performed. 

/SUBMIT 

Directs  XDACS  to  submit  the  command  file  generated  lor  the  builder 
to  a  batch  queue.  You  can  continue  to  issue  commands  in  your  current 
process  without  waiting  for  the  batch  job  to  complete.  The  builder 
output  is  written  to  a  batch  log  file. 

By  default,  the  generated  command  file  is  executed  in  a  subprocess 
(UNK/WAIT). 

/WAIT 

Directs  XDACS  to  execute  the  command  file  generated  for  the  builder 
in  a  subprocess.  Execution  of  your  cunent  process  is  suspended  until 
the  subprocess  completes.  The  builder  output  is  written  directly  to 
your  terminal.  Note  that  process  logical  names  are  propagated  to  the 
subprocess  generated  to  execute  the  command  file. 

By  default,  XDACS  executes  the  command  file  generated  for  the  builder 
in  a  subprocess;  you  must  wait  for  the  subprocess  to  terminate  before 
you  can  issue  another  command. 
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Parameter  Qualifiers 

lUBRARY 

Indicates  that  the  associated  input  file  is  an  object  module  library  to  be 
searched  for  modules  to  resolve  any  undefined  symbols  in  the  input 
files.  The  default  file  type  is  .XLB. 

By  default,  if  you  do  not  specify  the  /LIBRARY  qualifier,  the  file  is 
assumed  to  be  an  object  file  with  a  default  file  type  of  .XOB. 

/MAPPING 

Indicates  that  the  associated  input  file  is  a  mapping  definition  file. 
Mapping  definition  files  control  the  location  of  the  program  on  the 
target  system.  The  default  file  type  is  .MPD. 

By  default,  if  you  do  not  specify  the  /MAPPING  qualifier,  the  file  is 
assumed  to  be  an  object  file  with  a  default  hie  type  of  ,XOB. 

/TARGET 

Indicates  that  the  associated  input  hie  is  a  target  definihon  file.  Target 
definition  files  describe  the  target  system's  memory.  The  default  hie 
type  is  .TGD. 

By  default,  if  you  do  not  specify  the  /TARGET  qualiher,  the  file  is 
assumed  to  be  an  object  file  with  a  default  hie  tj^e  of  XOB. 


Examples 

1  XOACS>  LINK  CONTROL_LOOP 

\ACS'-I-CL_LINKING,  InvoKinq  the  XD  Ada  Builder 

The  LINK  command  forms  the  closure  of  the  unit  CONTROL_ 
LOOP,  which  is  an  XD  Ada  main  program,  creates  a  builder  com¬ 
mand  hie  and  package  eiaborahon  file,  then  invokes  the  command 
file  in  a  spawned  subprocess. 

2,  XDACS>  LINK/SUBHIT  CONTBOL_LOOP  LOOP_FUNCT:ONS/LIBRARY 

^ACS-I-CL_SUBMlTTEOr  Job  CONTBOL_LOOP  (queue  ALL^BATCH,  entry  134 t 
started  on  FAST^batch 

The  LINK  command  instructs  the  builder  to  link  the  closure  of  the 
XD  Ada  main  program  CONTROL_LOOP  against  the  library  LOOP. 
FUNCnONS.XLB.  The  /SUBMIT  qualifier  causes  XDACS  to  submit 
the  builder  command  file  as  a  batch  job 
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3  ;<DACS>  -IN'K/NCMAIN  F:.UI2_VCL!JME,  CCUNTER  MCN:rcR.x;3 
SACS-I-CI._LINKING,  [r.vokirvq  the  XD  Ada  Bui*der 

The  LINK  command  bmlds  the  XD  Ada  units  FLUID.VOLUME 
and  COUNTER  with  the  foreign  object  file  MONITOR. XOB.  The 
/NOMAIN  qualifier  tells  the  builder  that  the  image  transfer  address 
is  in  the  foreign  file. 
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XDADA 

Invokes  the  XD  Ada  compiler  to  compile 

;  one  or  more  source  files. 

Format 

XDADA  file-specl,...] 

Command  Qualifiers 

Defaults 

/LIBRARY  =  directory-spec 

/LIBRARY  ==  XDADASLIB 

Positional  Qualifiers 

Defaults 

/(NOlANALYSlS.DATAf  -  file-spec) 

/NOANALYSIS.DATA 

/(NOICHECK 

See  text. 

/(NOJCOPY.SOURCE 

/COPY.SOURCE 

/(N01DEBUG(-  (optionl,...Dl 

/DEBUG -ALL 

/(NOlDIAGNOSTICSt  -  file-spec) 

/NODIAGNOSTICS 

/(N01ERR0R_LIMlT(-n) 

/ERROR_LIMIT-30 

/(NO|LIST(- file-spec) 

/NOLIST 

/(NO]LOAD(- option] 

/LOAD -REPLACE 

/[NOjMACHINE_CODE(  -  option) 

/NOMACHINE_CODE 

/(NOINOTE.SOURCE 

/NOTE.SOURCE 

/(NOIOPTIMIZEf  -  option) 

See  text. 

/1N0)PREDEFINED_UN1T 

/NOPREDEFINED.UNIT 

/1N0)SH0W(- option) 

/SHOW -PORTABILITY 

/(NO)SYNTAX.ONLY 

/NOSYNTAX.ONLY 

/(NO)WARNINGS(»  (option).. ..D) 

See  text. 

Prompt 

.File; 

Command  Parameters 


ff/c-sp«c 

Specifies  one  or  more  XD  Ada  source  files  to  be  compiled.  If  you  do 
not  specify  a  file  type,  the  compiler  uses  the  default  file  type  of  ADA. 
No  wildcard  characters  are  allowed  in  the  file  specifications. 


B-2  XOAOA  Command  Definition 


XDADA 


If  you  specify  several  source  files  as  arguments  to  the  XDADA  com¬ 
mand,  you  must  separate  adjacent  file  specifications  with  a  comma  ( , ). 
If  you  specify  more  than  one  input  file,  you  must  separate  adjacent  file 
specifications  with  a  comma  (, ).  You  cannot  use  a  plus  sign  ( -t-  )  to 
separate  file  specifications. 


Description 

The  XDADA  command  is  one  of  four  commands  used  to  compile  com¬ 
pilation  units.  The  other  three  are  the  XDACS  COMPILE,  RECOMPILE 
and  LOAD  commands. 

The  XDADA  command  cam  be  used  at  any  time  to  compile  one  or 
more  source  files  (.ADA).  Source  files  are  compiled  in  the  order  they 
appear  on  the  command  line.  If  a  source  file  contains  more  tham  one 
compilation  unit,  they  au'e  compiled  in  the  order  they  appear  in  the 
source  file. 

The  XDADA  command  compiles  units  in  the  context  of  the  current 
program  library.  Whenever  a  compilation  unit  is  compiled  without 
error,  the  current  program  library  is  updated  with  the  object  module 
and  other  products  of  the  compilation. 


Command  Qualifiers 

/LIBRARY  a  d/rectory-spec 

Specifies  the  program  library  that  is  to  be  the  current  program  library 
for  the  duration  of  the  compilation.  The  d.'rectory  specified  must  be  an 
already  existing  XD  Ada  propam  library.  No  wildcard  characters  are 
allowed  in  the  directory  specification. 

By  default,  the  current  program  library  is  the  program  library  last 
specified  in  an  XDACS  SET  LIBRARY  command.  The  logical  name 
XDADASUB  is  assigned  to  the  program  library  specified  in  an  XDCAS 
SET  LIBRARY  conunand. 


Positional  Qualifiers 

/ANALYSIS_DATA{Bf/l9~5pec] 

INOANALYSIS_DATA  (D) 

Controls  whether  a  data  analysis  file  containing  source  code  cross- 
reference  and  static  analysis  information  is  created.  The  data  analysis 
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file  IS  supported  only  for  use  with  DIGITAL  layered  products 
the  VAX  Source  Code  Analyzer.  proaucts. 


such  as 


One  data  analysis  hie  is  created  for  each  source  file  compiled  The 
^fault  directory  for  data  analysis  hies  is  the  current  default  directory 
The  defau  t  h  e  name  is  the  name  of  the  source  file  being  compUed 

The  defa^t  hie  type  is  ANA.  No  wildcard  characters  are  allowed  in  the 
file  specificahon.  ^ 


By  default,  no  data  analysis  file  is  created. 


/CHECK 

/NOCHECK 

Controls  whether  all  run-time  checks  are  suppressed  The  INOCHECK 
qualifier  is  equivalent  to  having  all  possible  SUPPRESS  pragmas  in  the 


bjq^ucit  use  of  the  /CHECK  qualifier  overrides  any  occurrences  of  the 
pragmas  SUPPRESS  and  SUPPRESS.ALL  in  the  source  wSfiout 
the  need  to  edit  the  source  code. 


By  default,  run-time  checks  are  suppressed  only  in  cases  where 
pragma  SUPPRESS  or  SUPPRESS.ALL  appears  in  the  source. 


See  the  Reference  Manual  for  the  Ada  Programming  Language  foi  more 
informahon  on  the  pragmas  SUPPRESS  and  SUPPRESS  ALL. 


/COPY  SOURCE  (D) 
/NOCOPY_SOURCE 


Controls  whether  a  copied  source  file  (.ADC)  is  created  in  the  current 
*  compilation  unit  is  compiled  without  error  The 
RECOMPILE  command  (and  thus  the  COMPILE  command)  requires 
that  a  copied  source  file  exist  in  the  current  program  Ubrary  for  any  unit 
that  is  to  be  recompiled.  ^ 


By  default,  a  copied  source  file  is  created  in  the  current  program  library 
when  a  unit  is  compiled  without  error.  ^ 


/DEBUO[=(optton[,...J}]  (D) 

/NODEBUG 

Controls  which  compiler  debugging  options  are  provided  You  can 
debug  XD  Ada  programs  with  the  XD  Ada  Debugger.  You  can  request 
the  following  options:  ^ 
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ALL 

NONE 

INOISYMBOLS 

(NOITRACEBACK 


Provides  both  SYMBOLS  and  TRACEBACK. 

Provides  neither  SYMBOLS  nor  TRACEBACK. 

Controls  whether  debugger  symbol  records  are  in¬ 
cluded  in  the  object  file. 

Controls  whether  traceback  information  (a  subset  of 
the  debugger  symbol  information)  is  included  in  the 
object  file. 


By  default,  both  debugger  symbol  records  and  traceback  informarion  are 
included  in  the  object  file  (/DEBUG- ALL,  or  equivalently:  /DEBUG). 

I  DIAGNOSTfCS[= file-spec] 

/NODIAGNOSTICS  (D) 

Controls  whether  a  diagnostics  file  containing  compiler  messages  and 
diagnostic  information  is  created.  The  diagnostics  file  is  supported  only 
for  use  with  DIGITAL  layered  products,  such  as  the  VAX  Lsmguage- 
Sensitive  Editor. 

One  diagnostics  file  is  created  for  each  source  file  compiled.  The 
default  directory  for  diagnoshcs  files  is  the  current  default  directory. 

The  default  file  name  is  the  name  of  the  source  file  being  compiled. 

The  default  file  type  is  .DIA.  No  wildcard  characters  are  allowed  in  the 
file  specification. 

By  default,  no  diagnostics  file  is  created. 

/ERROR  UMIT[^n] 

INOERRORJJMIT 

Controls  whether  execution  of  the  XDADA  command  for  a  given 
compilation  unit  is  terminated  upon  the  occurrence  of  the  nth  E-level 
error  within  that  unit. 

Error  counts  are  not  accumulated  across  a  sequence  of  compilation 
units.  If  the  /ERROR. LIMIT  -  n  option  is  specified,  each  compilation 
unit  may  have  up  to  n-1  errors  without  terminating  the  compilation. 
When  the  error  linrut  is  reached  within  a  compilation  unit,  compilation  of 
that  unit  is  terminated,  but  compilation  of  subsequent  units  continues. 

The  /ERROR.LIMIT-0  option  is  equivalent  to  ERROR.LIMIT  - 1 . 

By  default,  execution  of  the  XDADA  command  is  terminated  for  a  given 
compilation  unit  upon  the  occurrence  of  the  30th  E-level  error  within 
that  unit  (equivalent  to  /ERROR.LIMIT -30). 
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IUST{  =  file-spec] 

INOUST  (D) 

Controls  whether  a  listing  file  is  created.  One  lis'.iiiie  f''>’  ; .  created 
for  each  source  file  compiled.  The  default  dir»'\^rv  r^i  listing  files  is 
the  current  default  directory.  The  default  file  name  is  the  name  of  the 
source  file  being  compiled.  The  default  file  type  is  .LIS.  No  wildcard 
characters  are  allowed  in  the  file  specification. 

By  default,  the  XDADA  command  does  not  a  listing  file. 

I  LOAD]  s  option]  (D) 

INOLOAD 

Controls  whether  the  current  program  library  is  updated  with  the 
successfully  processed  units  contained  in  the  specified  source  files. 
Depending  on  other  qualifiers  specified  (or  not  specified)  with  the 
XDADA  command,  processing  can  involve  full  compilation,  syntcix 
checking  only,  and  so  on.  The  /NOLOAD  qualifier  causes  the  units 
in  the  specified  source  files  to  be  processed,  but  prevents  the  current 
program  library  from  being  updated. 

You  cjui  specify  the  following  option: 

(NOIREPLACE  Controls  whether  a  unit  added  to  the  current 

program  library  replaces  an  existing  unit  with  the 
same  name.  If  you  specify  th*  NOREPLACE  option, 
the  unit  is  added  to  the  current  program  Library  only 
if  no  existing  unit  has  the  same  name,  except  if  the 
new  unit  is  the  corresponding  body  of  an  existing 
spedHcation  or  vice  versa. 

By  default,  the  current  program  library  is  updated  with  the  success¬ 
fully  processed  units,  and  a  unit  added  to  the  current  program  library 
replaces  an  existing  unit  with  the  same  name. 

IMACHINEjCODE]- option] 

I  NOMACHINE  _CODE  (D) 

Controls  whether  generated  machine  code  (approximating  assembly 
language  notation)  is  included  in  the  listing  file. 

You  can  specify  one  of  the  following  options: 
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SYMBOUC:NONE  Provides  machine  code  listing  with  no  annotation. 

SYMBOL1C;NORMAL  Provides  machine  code  in  the  listing  file;  where 

possible,  instructions  are  annotated  with  simple  Ada 
names. 

SYMBOUCiMAXlMAL  Provides  machine  code  in  the  listing  file;  where 

possible,  instructions  are  annotated  with  Ada  names, 
in  expanded  form  if  necessary. 

The  /MACHINE_CODE  qualifier  without  options  is  equivalent  to 
/MACHINE.CODE  -  SYMBOUC:NORMAL. 

/NOTE  SOURCE  (D) 

I  NONOTE  _SOURCE 

Controls  whether  the  file  specification  of  the  source  fife  is  noted  in  the 
program  library  when  a  unit  is  compiled  without  error.  The  COMPILE 
command  uses  this  information  to  locate  revised  source  files. 

By  default,  the  file  specification  of  the  source  file  is  noted  in  the  pro¬ 
gram  library  when  a  unit  is  compiled  without  error. 

lOPTIMIZE[=(optlonl,  .  .  .  ]) 

/NOOPTIMIZE 

Controls  the  level  of  optimization  that  is  applied  in  producing  the 
compiled  code.  You  can  specify  one  of  the  following  primary  options: 

TIME  Provides  full  optimization  with  time  as  the  primarv 

optimization  criterion.  Overrides  any  occurrences  of 
the  pragma  OPTlMI2E(SPACE)  in  the  source  code. 

SPACE  Provides  full  optimization  with  space  as  the  primary 

optimization  criterion.  Overrides  any  occurrences  of 
the  pragma  OPTlMlZEfTIME)  in  the  source  code. 

DEVELOPMENT  Suggested  when  active  development  of  a  program 

is  in  progress.  Provides  some  optimization,  but 
development  considerations  and  ease  of  debugging 
take  preference  over  optimization.  This  option 
overrides  pragmas  that  establish  a  dependence  on  a 
subprogram  (the  pragma  INLINE),  and  thus  reduces 
the  need  for  recompilations  when  such  bodies  are 
modified. 

NONE  Provides  no  optimization.  Suppresses  ext 'i  'ons  in 

line  of  subprograms,  including  those  speofied  by  the 
pragma  INLINE. 

The  /NOOPTIMIZE  qualifier  is  equivalent  to  /OPTIMIZE -NONE. 
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By  default,  the  XDADA  command  applies  full  optimization  with  time 
as  the  primary  optimization  criterion  (like  /OPTIMIZE  -  TIME,  but 
observing  uses  of  the  pragma  OPTIMIZE). 

The  /OPTIMIZE  qualifier  also  has  a  set  of  secondary  options  that  you 
can  use  separately  or  together  with  the  primary  options  to  override  the 
default  behavior  for  inline  expansion  and  code  motion. 

The  INLINE  secondary  option  can  have  the  following  values; 

INLINE;  NONE  Disables  subprogram  expansion  in  line.  This  option 

overrides  any  occurrences  of  the  pragma  INLINE 
in  the  source  code,  without  having  to  edit  the 
source  file.  It  also  disables  implicit  expansion  in 
line  of  subprograms.  (Implicit  expansion  in  line  means 
that  the  compiler  assumes  a  pragma  INLINE  for 
certain  subprograms  as  an  optimization.)  A  call  to  a 
subprogram  in  another  unit  is  not  expanded  in  line, 
regardless  of  the  /OPTIMIZE  options  in  effect  when 
that  unit  was  compiled. 

INLINE:  NORMAL  Provides  normal  subprogram  expansion  in  line. 

Subprograms  to  which  an  explicit  pragma  INLINE 
applies  are  expanded  in  line  under  certain  condi¬ 
tions.  In  addition,  some  subprograms  are  implicitly 
expanded  in  line.  The  compiler  assumes  a  pragma 
INLINE  for  calls  to  some  small  local  subprograms 
(subprograms  that  are  declared  in  the  same  unit  as 
the  unit  in  which  the  call  occurs). 

INL1NE:SUBPR0GRAMS  Provides  maximal  subprogram  expansion  in  line.  In 
addition  to  the  normal  subprogram  expansion  in 
line  that  occurs  when  INUNErNORMAL  is  specified, 
this  option  results  in  implicit  expansion  in  line  of 
some  small  subprograms  declared  in  other  units. 

The  compiler  assumes  a  pragma  INLINE  for  any 
subprogram  if  it  improves  execution  speed  and 
reduces  code  size.  This  option  may  establish  a 
dependence  on  the  body  of  another  unit,  as  would  be 
the  case  if  a  pragma  INLINE  were  specified  explicitly 
in  the  source  code. 
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INUNEiMAXIMAL  Provides  maximal  subprogram  expansion  in  line. 

Maximal  subprogram  expansion  in  line  occurs  as  for 
lNUNE;SUBPROGRAMS. 

1NLINE:GENERICS  Provides  normal  subprogram  inline  expansion  and 
maximal  generic  inline  expansion.  With  this  option, 
subprogram  inline  expansion  occurs  in  the  same 
manner  as  for  INLINE:  NORMAL.  The  compiler 
assumes  a  pragma  INUNE.GENERIC  for  every 
instantiation  in  the  unit  being  compiled  unless 
a  generic  body  is  not  available.  This  option  may 
establish  a  dependence  on  the  body  of  another  unit, 
as  would  be  the  case  if  a  pragma  INUNE.GENERIC 
were  specified  explicitly  in  the  source  code. 

The  MOTION  secondary  option  can  have  the  following  values: 

MOTION: NONE  Disables  code  motion  optimizations. 

MOTION: LOOPS  Permits  code  motion  optimization  of  loops.  Where 

the  compiler  detects  that  a  loop  body  contains 
invariant  processing,  it  may  generate  code  in  which 
this  processing  is  performed  before  entry  to  the  loop 
instead  of  within  the  loop. 

MOTION:MAXIMAL  Permits  all  code  motion  optimizations.  In  addition 
to  the  optimization  of  loops  that  occurs  when 
MOnON:LOOPS  is  specified,  this  option  permits 
analogous  optimization  of  If  and  case  statements: 
where  the  compiler  detects  that  the  branches  of  an  If 
or  case  statement  contain  common  processing,  it  may 
generate  code  in  which  this  processing  is  performed 
before  evaluation  of  the  corresponding  condition  or 
case  expression  irutead  of  within  the  branches. 

By  default,  the  (OPTIMIZE  qualifier  primary  options  have  the  following 
secondary-option  values: 

/OPTIMIZE  .TIME  -(INUNE:NORMAL.MOTION:LOOPS) 

/OPTIMIZE  -  SPACE  -  (INUNE:NORMAL,  MOTION:  MAXIMAL) 

/OPTIMIZE -DEVELOPMENT  =(INUNE:NONE.MOTION:NONE) 

/OPTIMIZE -NONE  -(INUNE:NONE,MOTION:NONE) 

/PREDEFINED  UNIT 
/NOPREDEFINED_UNIT  (D) 

Controls  the  compilation  of  package  $RUN_TIME_SYSTEM,  pack¬ 
age  STASKING.SYSTEM,  and  package  MACHINE.CODE.  You  must 
specify  this  qualifier  in  order  to  be  able  to  compile  these  packages. 
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The  qualifier  is  trot  required  for  the  compilation  of  any  other  source 
files.  See  the  XD  Ada  MC68020  Run-Time  Reference  Manual  for  more 
information. 

By  default,  /PREDEFINED.  UN  IT  is  omitted. 

/SHOW[  ^  option]  (D) 

/NOSHOW 

Controls  the  listing  file  options  included  when  a  listing  file  is  provided. 
You  can  specify  one  of  the  following  options; 

ALL  Provides  all  listing  file  options. 

[NOIPORTABIUTY  Controls  whether  a  program  portability  summary 

is  included  in  the  listing  file.  By  default,  the 
XDADA  command  provides  a  portability  sum¬ 
mary  (/SHOW- PORTABILITY).  See  Appendi;  E 
for  details  of  what  can  be  included  in  a  porta¬ 
bility  summary.  See  Chapter  5  of  Version  2.0  of 
Developing  Ada  Programs  on  VMS  Systems  for  more 
information  on  program  portability. 

none  Provides  none  of  the  listing  file  options  (same  as 

/NOSHOW). 

By  default,  the  XDADA  command  provides  a  portability  summary 
(/SHOW  -  PORTABILITY) . 

ISYNTAXJONLY 
/NOSYNTAX_ONLY  (D) 

Controls  whether  the  source  file  is  to  be  checked  only  for  correct  syntax. 
If  you  specify  the  /SYNTAX.ONLY  qualifier,  other  compiler  checks  are 
not  performed  (for  example,  semantic  analysis,  type  checking,  and  so 
on). 

By  default,  the  compiler  performs  all  checks. 

fWARNINQS]  -  (nt0ssag9-optlon[, ...})] 

INOWARNINQS 

Controls  which  categories  of  informational  (1-level)  and  warning  (W- 
level)  messages  arc  displayed  and  where  those  messages  are  displayed. 
You  can  specify  any  combination  of  the  following  message  options; 

WARNINGS;  {deshnahon[,...\) 

NOWARNINGS 

WEAK.WARNINGS;  (deshnatwn[.. . . |) 
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XDADA 


NOWEAK.  WARNINGS 

SUPPLEMENTAL;  (destination[,...]) 
NOSUPPLEMENTAL 

COMPILATION  NOTES;  (destmation[....]) 
NOCOMPILATION.NOTES 

STATUS:  {destinaHon[,...]) 

NOSTATUS 


The  possible  values  of  destination  are  ALL,  NONE,  or  any  combination 
of  TERMINAL  (termiiral  device),  LISTING  (listing  file),  DIAGNOSTICS 
(diagnostics  file).  The  message  categories  are  summarized  as  follows: 


WARNINGS 

WEAK.WARNINGS 


SUPPLEMENTAL 

COMPILATION.NOTES 


STATUS 


W-level:  Indicates  a  definite  problem  in  a  legal 
program,  for  example,  an  unknown  pragma. 

l-level:  Indicates  a  potential  problem  in 
a  legal  program:  for  example,  a  possible 
CONSTRAJNT.ERROR  at  run  time.  These 
are  the  only  kind  of  I-level  messages  that  are 
counted  in  the  summary  statistics  at  the  end  of 
a  compilation. 

l-level;  Additional  information  associated  with 
preceding  E-level  or  W-level  diagnostics. 

l-level:  Information  about  how  the  compiler 
translated  a  program,  such  as  record  layout, 
parameter-passing  mechanisms,  or  decisions 
made  for  the  pragmas  INLINE,  INTERFACE,  or 
the  import-subprogram  pragmas. 

l-level:  End  of  compilation  statistics  and  other 
messages. 


The  defaults  are  as  follows. 

/WAWIINGS- (  WARN  t  ALL,  WEAK:  ALL,  SUPP:  ALL,  COMP  :;:CNE,STAT:  LI  ST) 

Note  that  abbreviations  are  valid. 

If  you  specify  only  some  of  the  message  categories  with  the 
/WARNINGS  qualifier,  the  default  values  for  other  categories  are  used. 
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XDADA 


Examples 

1  S  XDADA  MODEL_;:)TERFACE_,MODEL_INTERFACE,CONTROL_LCCP 

The  XDADA  command  compiles  the  compilation  units  con¬ 
tained  in  the  three  files  MODEL_INTERFACE_.ADA,  MODEL. 
INTERFACE. ADA,  and  CONTROL.LOOP.ADA,  in  the  order  given. 

2.  s  xdada/list/show-all  screen_io_,screen_io 

The  XDADA  command  compiles  the  compilation  units  contained 
in  the  two  files  SCREEN_IO_.ADA  and  SCREEN.IO.ADA,  in  the 
order  given.  The  /LIST  qualifier  creates  the  listing  files  SCREEN. 
IO_.LIS  and  SCREEN.IO.LIS  in  the  current  default  directory.  The 
/SHOW  -  ALL  qualifier  causes  all  listing  file  options  to  be  provided 
in  the  listing  files. 
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APPENDIX  C 

APPENDIX  F  OF  THE  Ada  STANDARD 


The  only  allowed  implementation  dependencies  correspond  to  implementation-dependent  pragmas, 
to  certain  machine-dependent  conventions  as  mention^  in  Chapter  13  of  the  Ada  Standard,  and  to 
certain  allowed  restrictions  on  representation  clauses.  The  implementation-dependent  characteristics 
of  this  Ada  implementation,  as  described  in  this  Appendix,  are  provided  by  the  customer.  Unless 
specifically  noted  otherwise,  references  in  this  Appendix  are  to  compiler  documentation  and  not  to 
this  report.  Implementation-speci&c  portions  of  the  package  STANDARD,  which  are  not  a  part  of 
Appendix  F,  are: 


package  STANDARD  is 


type  INTEGER  is  range  -2147483648  ..  2147483647; 
type  SHORT_INTEGER  is  range  -32768  ..  32767; 
type  SH0RT~SH0RT_INTEGER  is  range  -128  ..  127; 

type  FLOAT  is  digits  6  range  •(2**128  -  2**104)  ..  2**128  -  2**104; 

type  LONG_FLOAT  is  digits  15  range  •(2**1024  -  2**971)  ..  2**1024  -  2**971; 

type  LONG  LONG  FLOAT  is  digits  18  range  -(2*  *16384  -  2*  *16320)  ..  2**16384  - 
2**16320; 

type  DURA'flON  is  delta  l.OE-4  range  -131072.0000  ..  131071.9999; 


end  STANDARD; 


Validation  Sammary  lUport 


AVF_VSR_9050Z/73 
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Appendix  F 

Implementation-Dependent 

Characteristics 


F.3  Specification  of  Package  System 

The  package  SYSTEM  for  the  MC68000  configuration  differs  from  that 
of  the  standard  MC68020  as  follows; 


F.3.1  Package  SYSTEM  for  the  MC68000  Target 

For  MC68000,  she  system  description  has  been  redefined  as  follows; 

trp*  NAMf  is  (MC«8C00)! 

SYSTeM_NA»iE  s  eoBStast  NAME  MCS8000: 

STORAGE.UHIT  !  eoastaat  9: 

MEMORV_il2E  ••  eaaataat  s-  2*-24: 

tick  :  eoastaat  s-  2tl.O*E-l3: 

typa  ADDRESS_INT  Is  raa«a  0  ..  MEMORV_SI CE- 1 : 
for  ADDRESS_iMT'SICE  uso  22: 
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F.6  Interpretation  of  Expressions  Appearing  in  Address 
Clauses 


For  MC68020  address  clauses  on  variables,  the  address  expression  is 
interpreted  as  a  Motorola  32  bit  address.  For  MC68000,  it  is  interpreted 
as  a  Motorola  24-bit  address. 

In  XD  Ada  for  MC68020,  values  of  type  SYSTEM, ADDRESS  are  inter¬ 
preted  as  integers  in  the  range  0  2  '^  -1  For  XD  Ada  MC68000,  they 

are  interpreted  as  integers  in  the  range  0  2^^  -1 
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Appendix  F 

Implementation-Dependent 

Characteristics 


NOTE 

This  appendix  is  not  part  of  the  standard  definition  of  the 
Ada  progranuning  language. 

This  appendix  summarizes  the  following  implementation-dependent 
characterisdcs  of  XD  Ada: 

•  Listing  the  XD  Ada  pragmas  and  attributes. 

•  Giving  the  specification  of  the  package  SYSTEM. 

•  Presenting  the  restrictions  on  representation  clauses  and  unchecked 
type  conversions. 

•  Giving  the  conventions  for  names  denoting  implementation- 
dependent  components  in  record  representation  clauses. 

•  Giving  the  interpretation  of  expressions  in  address  clauses. 

•  Presenting  the  implementation-dependent  characteristics  of  the 
input-output  packages. 

•  Presenting  other  implementation-dependent  characteristics. 

References  all  apply  to  sections  in  the  XD  Ada  MC68020  Supplement  to 
the  Ada  Luinguage  Reference  Manual. 
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F .1  Inriplementation-OependGnt  Pragmas 


-  wiuwu  are  aennea  elsewhere 

in  the  text.  In  addition,  XD  Ada  restricts  the  predefined  laneuaee 
pragmas  INLINE  and  INTERFACE,  provides  pragma  VOLATILE  in 
addition  to  pragma  SHARED,  and  provides  pragma  SUPPRESS  ALL  in 
pragma  SUPPRESS.  See  Annex  B  for  a  descnptive  p'ragma 


•  CALL.SEQUENCE.FUNCnON  (see  Annex  B) 

•  CALL.SEQUENCE.PROCEDURE  (see  Annex  B) 

•  EXPORT. exception  (see  Section  13.9a.3.2) 

•  EXPORT.FUNCnON  (see  Section  13.9a.  1.2) 

•  EXPORT.OBJECT  (seo  Section  13.9a.2.2) 

•  EXPORT.PROCEDURE  (see  Section  13. 9a.  1.2) 

•  IMPORT.EXCEPnON  (see  Section  13.9a.3.1) 

•  IMPORT.FUNCnON  (see  Section  13.9a.l.l) 

•  IMPORT.OBJECT  (see  Section  13.9a.2.1) 

•  IMPORT.PROCEDURE  (see  Section  13.9a.l.l) 

•  LEVEL  (see  Section  13.5.1) 

•  LINK.OPTION  (see  Annex  B) 

•  SUPPRESS.ALL  (see  Section  11.7) 

•  TITLE  (see  Armex  B) 

•  VOLATILE  (see  Section  9.11) 


F.2  Implementation-Dependent  Attributes 

XD  Ada  provides  the  following  attributes,  which  are  defined  elsewhere 
in  the  text.  See  Appendix  A  for  a  descriptive  attribute  summary. 

•  BIT  (see  Section  13.7.2) 

•  MACHINE. SIZE  (see  Section  13.7.2) 

•  TYPE.CLASS  (see  Section  13. 7a. 2) 
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F.3  Specification  of  the  Package  System 

The  package  SYSTEM  for  the  MC68020  is  as  follows: 

paekag*  SYSTEM  la 

typa  NAME  la  (MCe8020); 

SYSTEM_NAMB  !  ceaataat  NAME  !-  MC6  8020; 

STORAoi.UNIT  :  eaaataat  i-  8; 

MEM0RY_il2E  :  eoaataat  i-  2**31-1; 

MIN_INT  :  eaaataac  i-  -(2**31); 

MAX~INT  :  eoaataat  i-  2**31-1; 

HAx'oiGITS  s  eoaataat  18; 

HAE~MANTISSA  >  eoaataat  i-  31: 

PINE_DBLTA  :  eoaataat  t-  2.0**(-31); 

tick”  :  eoaataat  i-  162.5B-6; 

aubtypo  PRIORITY  la  INTEGER  raago  0  ..  IS; 

aubtypo  LEVEL  la  INTEGER  raago  0  ..  7; 

—  Addroaa  typo 
typo  ADDRESS  la  prlvata; 

ADDRESS  ZERO  I  eoaataat  ADDRESS; 
typa  ADDRSSS.INT  la  raago  HIN^INT  ..  HAA_INT; 
faaetloa  TO_ADDRESS  (X  t  ADORBSS_INT) 

faaetloa  TO_ADDRESS  (X  i  (univoraal^intagarl ) 

faaetloa  TO~ADDRBSS_INT  (X  i  ADDRESS) 

faaetloa  (LEFT  i  ADDRESS;  RIGHT  ■  ADDRESS_INT)  rotara  ADDRESS; 

faaetloa  •*'  (LEFT  i  ADORESS_INT;  RIGHT  :  ADDRESsJ  rotara  ADDRESS; 

faaetloa  (LEFT  i  ADDRESS?  RIGHT  :  ADDRESS)  rotara  AD0RXSS_INT; 

faaetloa  *-*  (LEFT  i  ADDRESS;  RIGHT  i  ADDRESS_INT)  rotara  ADDRESS? 

—  faaetloa  (LEFT,  RIGHT  i  ADDRESS)  rotara  BOOLEAN; 

—  faaetloa  */-*  (LEFT,  RIGHT  i  ADDRESS)  rotara  BOOLEAN; 

faaetloa  *<*  (LEFT,  RIGHT  i  ADDRESS)  rotara  BOOLEAN; 

foaetioa  *<«*  (LEFT,  RIGHT  I  ADDRESS)  rotara  BOOLEAN; 

faaetloa  *>■  (LEFT,  RIGHT  <  ADDRESS)  rotara  BOOLEAN; 

faaetloa  *>•*  (LEFT,  RIGHT  t  ADDRESS)  rotara  BOOLEAN; 

-•  Note  that  becauae  ADDRESS  is  a  private  type 
--  the  functions  and  "/-*  are  already  available 

_  Generic  functions  used  to  access  menory 

goaorle 

typo  TARGET  la  prlTsta; 

faaetloa  FETCH_FRO«_ ADDRESS  (A  :  ADDRESS)  rotara  TARGET; 
poBorle 

typo  TARGET  Is  private; 

proeodare  ASSIGN_TO_ADDRESS  (A  >  ADDRESS;  T  t  TARGET); 


rotara  ADDRESS; 
rotara  ADDRESS; 
rotara  ADDRESS  INT; 
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typ«  rYPE_CLASS  ia  ( TYPE_CLASS_ENUMERATION , 
TYPB_CLASS_ INTEGER , 
TYPE_CLASS_FIXED_POINT, 
TVPE~CLASS~FLOATING_POINT, 

type'class^array  , 
type'class^record, 

TYPB^CLASS” ACCESS , 

T ype_class“task , 
TYPE_CLASS_ADDRBSS )  ; 


XD  Ada  hardwara-oriented  typea  and  lunctiona 


tfpm  BIT_ARRAY  la  array  (INTEGER  raa«a  <>) 
pra«aa  PACK ( BIT.ARRAY ) ; 

aalatypa  BIT_ARRAY_8  la  BIT_ARRAY  (0  ..  7); 

aab«ypa  BIT~ARRAY_16  la  BIT  AKRAY  (0  ..  15); 
aabtypa  BIt"aRRAY_32  la  BIT^ARRAY  (0  ..  31); 
aabtypa  BIT~ARRAY_64  la  BIt'aRRAY  (0  ..  63); 
typa  UNSIGNBD_BYTB  la  rufla  0  ..  255; 

far  UNSIGNEd'bYTB'SIZB  uaa  8; 

fuaetlaa  'not*  (LEFT  i  UNSIGNED_B¥TE ) 

fuaetlaa  'and*  (LEFT,  RIGHT  ■  UNSIGNED~BYTE) 
fuaetlaa  'or*  (LEFT,  RIGHT  t  UNSiaNED~BYTB) 
fuaetlaa  'xor'  (LEFT,  RIGHT  i  UNSIGNBD~BYTE) 


of  BOOLEAN; 


ratan  UNSIGNED_BYTE; 
ratara  UNSIQIBD^BYTB; 
ratara  UNSIGNBd'bYTE; 
ratara  UNSIGNBD^BYTE; 


fuaetlaa  TO_UNSIGNBD_BYTB  (X  ■  BIT_ARRAY_8)  ratara  UNSIGNBD_BYTB; 
fuaetlaa  To2bIT_ARHAY_8  (X  i  UNSIGNBD_BYTB )  ratara  BIT_ARRAy”8; 


typa  UNStaNED_BYTB_ARRAY  la  array  (INTEGER  raaga  <>)  of  UNSIGNBD_BYTE; 


typa  UNSIGNBD_WORD  la  raa«a  0  ..  65535; 

far  UNSIGNEO~HORD‘SIZB  aaa  16; 


fuaetlaa  'not'  (LEFT  t  UNSIGNBD_W0RD)  ratara  UNSiaNBD_MORO; 

fuaetlaa  'snd*  (LEFT,  RIGHT  t  UN5IGNBD~W0R0)  ratara  UNSIGNBo'wORO; 
fuaetlaa  'or*  (LEFT,  RIGHT  t  UNSIGNBD^HORO)  ratara  UNSIGNED* WORD; 
faaatlaa  'xor'  (LEFT,  RIGHT  i  unSIGNEd'hord)  ratara  unsigNED_word; 

fuaetlaa  TO  UNSIGNED  WORD  (X  t  aiT_ARRAY_18 )  ratara  UNSIGNBD_WORD; 
fuaetlaa  To”bIT_ARRAY_16  (X  :  UNsIgnBD_WORD)  ratara  BIT_ARRAY_16: 

typa  UNSIGNBO_WORO_ARRAY  la  array  (INTEGER  raaga  <>)  of  UNSIGNBD_WORD; 


typa  UNSIGNEO_LONGWORD  la  raaga  MIN_INT  ..  MAX_INT; 
far  UNSIGNED_LONGWORD'SIZE  uaa  32; 

fuaetlaa  'not'  (LEFT  i  UNSIGNED_LONGWCn? )  ratara  UNS I GNED_ LONGHORD ; 

fuaetlaa  'and*  (LEFT,  RIGHT  s  UNSIGNED^LONGWORD)  ratara  UNSIGNED^LONGWORD: 

fuaetlaa  'or'  (LEFT,  RIGHT  :  UNSIGNED_LONGWORD)  ratara  UNSIGNED_LONGWORD; 

fuaetlaa  'xor'  (LEFT,  RIGHT  «  UNSIGNED^LONGWORD l  ratara  UNSIGNEd'lONGWORD: 

fuaetlaa  TO  UNSIGNED_LONGWORD  (X  :  BIT_ARRAY_32 )  ratara  UNSIGNBD_LONGHORD; 
fuaetlaa  To”bIT_ARRAY_32  (X  :  UNSIGNio.woRD)  ratara  BIT_ARRAY_32 ; 

typa  UNSIGNED_LOWGWORO_ARRAY  la  array  (INTEGER  raaga  <>)  of  UNSIGNED_LONGWORD: 
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Conventional  namea  for  atatic  suDtypea  of  type  UNSIGNED_LCNGWORD 


subtype 

UNSIGNED_ 

1 

is 

UNSIGNED, 

LONGWORD 

r«ag« 

0  . 

.  2**  1-1 

subtype 

unsigned’ 

2 

la 

UNSIGNED^ 

LONGWORD 

rang* 

c  . 

.  2  * •  2-1 

subtype 

unsigned' 

3 

la 

UNSIGNED* 

LONGWORD 

raaga 

0  . 

.  2**  3-1 

subtype 

UNSIGNED_ 

4 

la 

UNSIGNED, 

LONGWORD 

raaga 

0  . 

.  2**  4-1 

subtype 

unsigned' 

5 

la 

UNSIGNED* 

LONGWORD 

raaga 

0  . 

.  2**  5-1 

subtype 

UNSIGNED^ 

6 

Is 

UNSIGNED^ 

LONGWORD 

raaga 

0  . 

.  2**  6-1 

subtype 

unsigned' 

7 

Is 

UNSIGNED, 

LONGWORD 

raaga 

0  . 

.  2**  7-1 

subtype 

UNSIGNED^ 

3 

is 

UNSIGNED^ 

LONGWORD 

raaga 

0  . 

.  2**  8-1 

subtype 

UNSIGNED^ 

9 

la 

UNSIGNED* 

LONGWORD 

raaga 

0  . 

.  2**  9-1 

subtype 

unsigned" 

10 

la 

UNSIGNED, 

LONGWORD 

raaga 

0  . 

.  2**10-1 

subtype 

unsigned' 

11 

Is 

UNSIGNED, 

LONGWORD 

raaga 

0  . 

.  2**11-1 

subtype 

unsigned' 

12 

is 

UNSIGNED, 

LONGWORD 

raaga 

0  . 

.  2**12-1 

subtype 

unsigned' 

13 

is 

UNSIGNED, 

LONGWORD 

raaga 

0  . 

.  2**13-1 

subtype 

UNSIGNED, 

14 

la 

UNSIGNED, 

LONGWORD 

raaga 

0  . 

.  2**14-1 

subtype 

unsigned' 

10 

Is 

UNSIGNED, 

LONGWORD 

raaga 

0  . 

.  2**15-1 

subtype 

unsigned' 

16 

la 

UNSIGNED* 

LONGWORD 

raaga 

0  . 

.  2**16-1 

subtype 

unsigned' 

17 

Is 

UNSIGNED, 

LONGWORD 

raaga 

0  . 

.  2**17-1 

subtype 

unsigned' 

18 

Is 

UNSIGNED* 

LONGWORD 

raaga 

0  . 

.  2**18-1 

sabtype 

unsigned]] 

19 

is 

UNSIGNED, 

LONGWORD 

raaga 

0  . 

.  2**19-1 

aubtype 

UNSIGNED* 

20 

is 

UNSIGNED* 

LONGWORD 

raaga 

0  . 

.  2«*20-l 

subtype 

UNSIGNED* 

21 

is 

UNSIGNED  LONGWORD 

raaga 

0  . 

.  2**21-1 

sabtype 

UNSKWED* 

22 

la 

UNSIGNED 

LONGWORD 

raaga 

0  . 

.  2*«22-l 

subtype 

UNSIGNED* 

23 

is 

UNS I GNED_  LONGWORD 

raaga 

0  . 

.  2**23-l 

sabtype 

UNSIGNED* 

24 

is 

UNS I  GNED~  LONGWORD 

raaga 

0  . 

.  2«*24-l 

sabtype 

UNSIGNED* 

25 

ia 

UNSIGNED, 

LONGWORD 

raaga 

0  . 

.  2**25-l 

sabtype 

UNSIGNED* 

26 

ia 

UNSIGNED* 

LONGWORD 

raaga 

0  . 

.  2**26-l 

sabtype 

UNSIGNED* 

27 

ia 

UNS I GNED, LONGWORD 

raaga 

0  . 

,  2**27-l 

sabtype 

UNSIGNED* 

28 

is 

UNS I GNED*  LONGWORD 

raaga 

0  . 

.  2**28-l 

sabtype 

UNSIGNED  29 

Is 

UNS  I  GNEd]]  LONGWORD 

raaga 

0  . 

.  2**29-l 

sabtype 

UNSIGNED 

30 

ia 

UNSIGNED^LONGWORD 

raaga 

0  . 

.  2*»30-l 

sabtype 

UNSIGNED,! I 

ia 

UNS I GNEd3 LONGWORD 

raaga 

0  . 

.  2**31-1 

private 

—  Not  ahown 
aB4  SYSTEM; 


F.4  Restrictions  on  Representation  Clauses 

The  representation  clauses  allowed  in  XD  Ada  are  length,  enumeration, 
record  representation,  and  address  clauses. 

In  XD  Ada,  a  representation  clause  for  a  generic  formal  type  or  a  type 
that  depends  on  a  generic  formal  type  is  not  allowed.  In  addition,  a 
representation  clause  for  a  composite  type  that  has  a  component  or 
subcomponent  of  a  generic  formal  type  or  a  type  derived  from  a  generic 
formal  type  is  not  allowed. 
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Restnctions  on  length  clauses  are  specified  in  Section  13.2;  restnctions 
on  enumeration  representation  clauses  are  specified  in  Secrion  13.3;  and 
restrictions  on  record  representahon  clauses  are  specified  in  Section 
13.4. 


F.5  Conventions  for  Implementation-Generated  Names 
Denoting  Implementation-Dependent  Components  in 
Record  Representation  Clauses 

XD  Ada  does  not  allocate  implementation-dependent  components  in 
records. 


F.6  Interpretation  of  Expressions  Appearing  in  Address 
Clauses 

Expressions  appearing  in  address  clauses  must  be  of  the  type  ADDRESS 
defined  in  pacluige  SYSTEM  (see  Section  I3.7a.l  and  Section  F.3). 

XD  Ada  allows  address  clauses  for  variables  (see  Section  13.5).  For 
address  clauses  on  variables,  the  address  expression  is  interpreted  as  a 
Motorola  full  32-bit  address. 

XD  Ada  supports  address  clauses  on  task  entries  to  allow  interrupts  to 
cause  a  reschedule  directly.  For  address  clauses  on  task  entries,  the 
address  expression  is  interpreted  as  a  Motorola  exception  vector  offset. 

In  XD  Ada  for  MC68020,  values  of  type  SYSTEM.ADDRESS  are  inter¬ 
preted  as  integers  in  the  range  0  ..  2^^  -1.  As  SYSTEM.ADDRESS  is 
a  private  type,  the  only  operations  allowed  on  objects  of  this  type  are 
those  given  in  package  SYSTEM. 


F.7  Restrictions  on  Unchecked  Type  Conversions 

XD  Ada  supports  the  generic  function  UNCHECKED.CONVERSION 
with  the  restrictions  given  in  Section  10.3.2. 
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F.8  Implementation-Dependent  Characteristics  of 
Input-Output  Packages 

The  packages  SEQUENTIAL.IO  and  DIRECT_IO  are  implemented  as 
null  packages  that  conform  to  the  specification  given  in  the  Reference 
Manual  for  the  Ada  Programming  Language.  The  packages  raise  the  ex¬ 
ceptions  specified  in  Chapter  14  of  the  Reference  Manual  for  the  Ada 
Programming  Language.  The  three  possible  exceptions  that  are  raked  by 
these  packages  are  given  here,  in  the  order  in  which  they  are  raised. 


Exception 

When  Raiaed 

STATUS.ERROR 

Raised  by  an  attempt  to  operate  upon  or  close  a  Hie 
that  is  not  open  (no  Hies  can  be  opened). 

NAME.ERROR 

Raised  if  a  Hie  name  is  given  with  a  call  of  CREATE 
or  OPEN. 

USE.ERROR 

Raised  if  exception  STATUS.ERROR  is  not  raised. 

MODE_ERROR  cannot  be  raised  since  no  file  can  be  opened  (therefore 
it  cannot  have  a  current  mode). 

The  predefined  package  LOW_LEVEL_IO  is  not  provided. 


F.8.1  The  Package  TEXTJO 

The  package  TEXT.IO  conforms  to  the  specification  pven  in  the 
Reference  Manual  for  the  Ada  Programming  Language.  String  input- 
output  is  implemented  as  defined.  FUe  input-output  is  supported  to 
STANDARD.INPUT  and  STANDARD.OUTPUT  only.  The  possible 
exceptions  that  are  raised  by  package  TEXT.IO  are  as  follows: 
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Exception 

When  Raised 

STATUS.ERROR 

Raised  by  an  attempt  to  operate  upon  or  close  a  file 
that  is  not  open  (no  Kies  can  be  opened). 

NAME.ERROR 

Raised  if  a  file  name  is  given  with  a  call  of  CREATE 
or  OPEN. 

MODE.ERROR 

Raised  by  an  attempt  to  read  from,  or  test  for 
the  end  of,  STANDARD  OUTPUT,  or  to  write  to 
STANDARD.INPUT. 

END.ERROR 

Raised  by  an  attempt  to  read  past  the  end  of 
STANDARD.INPUT. 

USE.ERROR 

Raised  when  an  unsupported  operadon  is  attempted, 
that  would  otherwise  legal. 

The  type  COUNT  is  defined  as  follows; 

typa  COUNT  la  raa«a  0  •.  INTEGER' LAST; 

The  subtype  FIELD  is  defined  as  follows: 

typ*  FIELD  la  INTEGER  raaga  0  ..  132; 


F.8.2  The  Package  lO.EXCEPTIONS 

The  specification  of  the  package  lO.EXCET  JNS  is  the  same  as  that 
given  in  the  Reference  Manual  for  the  Ada  Programming  Language. 


F.9  Other  Implementation  Characteristics 

Implementation  characteristics  associated  with  the  definition  of  a  main 
program,  various  numeric  ranges,  and  implementation  limits  are  sum¬ 
marized  in  the  following  sections. 


F.9.1  Definition  of  a  Main  Program 

Any  library  procedure  can  be  used  as  a  main  program  provided  that  it 
has  no  formal  parameters. 
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F.9.2  Values  of  Integer  Attributes 

The  ranges  of  vciiues  for  integer  types  declared  in  package  STANDARD 
are  as  follows; 

SHORT_SHORTJNTEGER  -lU  ..  i  -\  (-128  ..  127) 

SHORT.INTEGER  -2*’  ..  2'^  -1  (-32768  ..  32767) 

INTEGER  -2^'  ..  2^'  -1  (-2147483648..  2147483647) 

For  the  package  TEXT_IO,  the  range  of  values  for  types  COUNT  and 
FIELD  are  as  follows; 

COUNT  0  ..  2^‘  -1  (0  ..  2147483647) 

FIELD  0  ..  132 


F.9.3  Values  of  Floating-Point  Attributes 

Floating-point  types  are  described  in  Section  3.5.7.  The  representation 
attributes  of  floating-point  types  are  summarized  in  the  following  table; 
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FLOAT 

LONG.FLOAT 

LONG.LONG.FLOAT 

DIGITS 

6 

15 

18 

SIZE 

32 

64 

96 

MANTISSA 

21 

51 

61 

EMAX 

84 

204 

244 

EPSILON 

2-:o 

2-30 

2-'® 

SMALL 

2-85 

2-205 

2-245 

lj\RGE 

2»‘-2“ 

220*2153 

2244_2»M 

SAFE.EMAX 

125 

1021 

16382 

safe.small 

2-126 

2*1022 

2*163U 

SAFE.LARGE 

2i2S_2>o* 

2^021  2^^ 

2l63i2_2l6321 

FIRST 

_^2'028_2*^') 

LAST 

2i2a_2*^ 

21024^2^^* 

2l63B4_2l6320 

MACHINE.RADIX 

2 

2 

2 

MACWNE.MANTISSA 

24 

53 

64 

MACHINE.EMAX 

128 

1024 

16384 

MACHINE.EMIN 

-125 

-1021 

-16382 

MACHINE.ROUNDS 

FALSE 

FALSE 

FALSE 

MACHUME.OVERFLOWS 

FALSE 

FALSE 

FALSE 
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F.9.4  Attributes  of  Type  DURATION 


The  values  of  the  significant  attributes  of  type  DURATION  are  as 
follows: 


DURATION 'DELTA 
DURATION 'SMALL 
DURATION 'FIRST 
DURATION 'LAST 


l.E-4 

2/n.0#E-14 

-131072.0000 

131071.9999 


(10-*) 

(2-'*) 

(-2‘") 

(2'U' DELTA) 


F.9.5  Implementation  Limits 


Limit 

Description 

255 

Maximum  identifier  length  (number  of  characters) 

255 

Maximum  number  of  characters  in  a  source  line 

2^0 

Maximum  number  of  library  units  and  subunits  in 
closure' 

a  compilation 

2‘^ 

Maximum  number  of  library  units  and  subunits  in 
closure^ 

an  execution 

2“  -1 

Maximum  number  of  enumeration  literals  in  an  enumeration 
type  defirtition 

2“  -1 

Maximum  number  of  lines  in  a  source  Hie 

2*’  -1 

Maximum  number  of  bits  in  any  object 

2“  -1 

Maximum  number  of  exceptions 

'Tht  compilation  cloaure  of  a  given  unit  ia  the  total  set  of  units  that  the  given  unit 
depends  on.  directly  and  indirectly. 

^The  execution  closure  of  a  given  unit  is  the  compilation  closure  plus  all  associated 
secondary  units. 
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Appendix  F 

Implementation-Dependent 

Characteristics 


This  appendix  describes  Version  1.2  additions  to  the  range  of 
implementation-dependent  pragmas,  and  enhancements  to  the  func¬ 
tionality  of  Package  TEXT.IO.  It  supplements  information  supplied  in 
the  Version  1.0  version  of  this  appendix. 


F.1  implementation-Dependent  Pragmas 

XD  Ada  MC68020  Version  1.2  supplies  three  new  pragmas,  DIRECT. 
INTERRUPT.ENTRY,  IDENT  and  TIME.SLICE.  In  the  foUowing  full 
list  of  supported  pragmas,  references  refer  to  sections  in  the  XD  Ada 
MC68Q2Q  buppUment  to  the  Ada  Language  Reference  Manual,  unless  updated 
by  sections  supplied  in  this  manual. 

•  CALL.SEQUENCE.PUNCnON  (see  Annex  B) 

•  CALL.SEQUENCE.PROCEDURE  (see  Annex  B) 

•  DIRECT.INTERRUPT.ENTRY  (see  Section  13.5.1) 

•  EXPORT.EXCEPnON  (see  Section  13.9a.3.2) 

•  EXPORT.FUNCnON  (see  Section  13.9a.l.2) 

•  EXPORT.OBJECT  (see  Section  13.9a.2.2) 

•  EXPORT. PROCEDURE  (see  Section  13.9a.l.2) 

•  IDENT  (see  Aimex  B) 

•  IMPORT.EXCEPTION  (see  Section  13.9a.3.1) 

•  IMPORT.FUNCnON  (see  Section  13.9a.l.l) 
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•  IMPORT_OBJECT  (see  Section  13.9a.2.1) 

•  [MPORT.PROCEDURE  (see  Section  13.9a.  1.1) 

•  LEVEL  (see  Section  13.5.1) 

•  LINK_OPnON  (see  Annex  B) 

•  SUPPRESS_ALL  (see  Section  11.7) 

•  TITLE  (see  Annex  B) 

•  TIME_SLICE  (see  Section  9.8a) 

•  VOLATILE  (see  Section  9.11) 


F.8.1  The  Package  TEXTJO 

The  package  TEXT.IO  conforms  to  the  specification  given  in  the 
Reftmce  Monuni  for  the  Ada  Programming  iMguage.  Parage  TEXT.IO,  as 
supplied  by  XD  Ada  MC68020  Version  1.2,  has  changed  as  follows; 

•  The  Run-Time  System  now  supports  asynchronous  input-output 
operatiorts,  where  a  TEXT.IO  operation  will  cause  only  the  task 
that  performs  the  operation  to  suspeitded  awaiting  its  com¬ 
pletion,  rather  than  all  the  tasks  in  the  prooam.  You  enable  this 
facility  by  compiling  the  file  XDADA$TARGET_SOURCE:ASYNC_ 
TERMINAL.IO.ADA  into  your  program  library,  as  described  in 
the  XD  Ada  MC68020  Version  1.2  New  Features  Manual.  You  dis¬ 
able  asynchronous  TEXT.IO  operations  by  compiling  the  file 

XD  AD  A$TARGET_SOURCE:TERMINALJo  .  ADA  into  yoiu  pro¬ 
gram  library. 

•  Support  is  provided  for  target  input-ou^t  to  be  directed  to  logical 
input  and  output  streants  on  the  host.  This  facility  is  available  for 
both  the  XDDEBUG  and  XDRUN  conunands. 

Input  and  output  are  buffered.  For  input,  all  characters  up  to  an 
end  of  line  or  end  of  page  are  made  available  to  the  target  program 
before  further  characters  are  read.  For  output,  the  buffer  is  flushed 
following  an  end  of  line  or  end  of  page.  See  the  XD  Ada  MC68020 
Version  1.2  New  Features  Manual  for  details  of  the  TEXT.IO  data 
objects  that  control  this  behavior. 

Note  that  if  XDADASINPUT  and  XDADASOUTPUT  are  defined  but 
opening  the  file  gives  an  error,  for  example  the  file  does  not  exist, 
the  filename  is  invalid  or  no  read/write  permission  is  assigned,  the 
file  is  treated  as  empty. 
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types  can  be  packed  as  components  of  composite  types,  as  well  as 
information  on  how  these  types  are  packed. 

A  record  component  that  begins  a  variant  is  always  allocated  at  the  next 
byte  boundary;  a  variant  that  begins  on  other  than  a  byte  boundary  can 
be  obtained  only  with  a  record  representation  clause. 

XD  Ada  provides  no  additional  representation  pragmas. 

The  following  information  supplements  paragraph  14: 

XD  Ada  does  not  allow  a  representation  clause  for  a  type  that  depends 
on  a  generic  formal  type.  A  type  depends  on  a  generic  formal  tj^e 
if  it  has  a  subcomponent  of  a  generic  formal  type  or  a  subcomponent 
that  depends  on  a  generic  formal  type,  or  if  it  is  derived  from  a  generic 
formal  type  or  a  type  that  depends  on  a  generic  formal  type. 


13.2  Length  Clauses 

The  following  information  supplements  paragraph  6: 

In  XD  Ada,  for  a  discrete  type,  the  given  size  must  not  exceed  32 
(bits).  The  given  size  becomes  the  default  allocation  for  all  objects  and 
components  (in  ’'rrays  and  records)  of  that  type.  However,  sizes  of 
objects  may  be  increased  by  the  compiler  for  optimization  purposes. 

For  integer  and  enumeration  types,  the  given  size  affects  the  internal 
representation  as  follows;  for  integer  types,  high  order  bits  are  sign- 
extended;  for  enumeration  types,  the  high  order  bits  may  be  either 
zero-  or  sign-extended  depending  upon  the  base  representation  that 
is  selected.  For  ail  other  types,  the  given  size  must  equal  the  size  that 
would  apply  in  the  absence  of  a  size  specification. 

The  following  information  supplements  paragraph  8: 

The  specification  of  a  collection  size  is  interpreted  as  follows.  If  the 
value  of  the  expression  is  greater  than  or  equal  to  zero,  the  specified 
size  (representing  the  number  of  bytes  in  the  collection)  is  rounded  up 
to  the  longword  boundary  nearest  (4  bytes),  and  is  then  used  as  the 
initial  size  of  the  collection;  the  collection  is  not  extended  should  that 
initial  allocation  be  exhausted.  In  the  absence  of  a  T'STORAGE_SIZE, 
no  storage  is  initially  allocated  for  the  collection;  storage  is  allocated 
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There  are  two  ways  an  interrupt  entry  can  be  handled,  according  to 
whether  or  not  the  task  has  a  pragma  LEVEL.  The  XD  Ada  MC68020 
Run-Time  Reference  Manual  gives  examples  of  interrupt  handlers. 

Tasks  with  interrupt  entries  but  no  pragma  LEVEL  run  at  interrupt  level 
0  only  while  accepting  an  interrupt  in  a  rendezvous.  Other  interrupts  of 
the  same  level  or  lower  levels  are  inhibited  while  in  the  handler.  It  is, 
however,  possible  to  lose  interrupts  with  this  method. 

Tasks  with  interrupt  entries  and  a  pragma  LEVEL  always  run  at  interrupt 
level,  whether  iruide  or  outside  a  rendezvous.  This  enables  the  user  to 
avoid  losing  interrupts. 

An  interrupt  entry  to  a  task  with  the  pragma  LEVEL  behaves  like  an 
ordirtaty  entry  call.  An  interrupt  entry  to  a  task  with  no  pragma  LEVEL 
behaves  Uke  a  conditional  ent^  call.  If  there  is  an  accept  statement 
waiting  for  the  interrupt,  the  b^y  of  the  accept  statement  is  executed 
inuncdiately.  When  the  body  is  complete,  the  task  is  inserted  in  the 
ready  queue  and  the  interrupt  completed  by  a  retum-from-interrupt 
instrucdon.  The  accept  statement  can  call  subprograms  and  make  entry 
calls,  but  must  not  suspend  the  task  before  the  interrupt  is  dismissed, 
otherwise  the  program  repeatedly  services  the  interrupt  unsuccessfully. 

Writing  interrupt  handlers  in  XD  Ada  requires  detailed  knowledge  of 
the  behavior  of  the  target  computer's  interrupt  system.  It  is  not  possible 
simply  to  place  a  use  clause  on  an  entry  to  achieve  the  desired  effect. 

NotrtuJ  Ada  interrupt  entries  cause  a  tasking  reschedule  each  time  an 
interrupt  occurs.  This  inevitably  incurs  a  performance  overhead,  and 
may  mean  that  interrupts  are  not  serviced  quickly  enou^.  In  order  to 
avoid  this  problem,  XD  Ada  suppUes  pragma  DIRECT.DTTERRUPT. 
ENTRY,  wMch  causes  the  interrupt  entry  to  be  connected  directly  to 
the  required  interrupt  vector.  This  run  time  efficiency  greatly  improves 
response  times.  The  form  of  this  pragma  is  as  follows: 

omiCT_IHTBRRUI>T_»lTRY(  int*rrupt_entry )  ; 

Pragma  DIRECT. INTERRUPT_ ENTRY  may  be  used  where  the  pro¬ 
gram  adheres  to  one  of  two  supported  code  models.  In  fact,  most 
applicatioiu  will  luturally  adhere  to  one  or  other  of  the  models,  so  the 
practical  restrictiorm  from  this  requirement  are  miniirud.  The  use  of 
pragma  DIRECT_INTERRUPT_ENTkY  must  meet  certain  semantic  con- 
didotu.  These,  along  with  the  checks  carried  out  by  the  compiler  and 
run-time  system,  are  described  in  full  in  the  XD  Ada  MC68020  Run-Time 
Reference  Manual  part  of  this  manual. 
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Chapter  13 

Representation  Clauses  and 
Implementation-Dependent 

Features 


The  text  in  this  chapter  lists  the  differences  between  XD  Ada  MC68000 
and  XD  Ada  MC68020,  as  described  in  the  XD  Ada  MC68020  Supplement 
to  the  Ada  Langtmge  Reference  Manual. 


13.1  Representation  Clauses 

The  following  information  replaces  the  MC68020  supplement  to  para¬ 
graph  13; 

Pragma  PACK  is  implemented  in  XD  Ada.  As  the  behaviour  of  pragma 
PACK  is  implementation  dependent,  users  are  advised  to  use  represen¬ 
tation  clauses  to  ensure  a  particular  representation  across  targets. 

In  XD  Ada  MC68000,  all  array  and  record  components  are  aligned 
according  to  their  types  by  default;  the  effect  of  pragma  PACK  on  a 
record  or  array  is  to  cause  those  components  which  are  packable  to  be 
allocated  in  adjacent  bits  without  regard  to  byte  bondaries.  Whether 
any  parhcular  component  is  packable  depends  on  the  rules  for  its  type; 
the  XD  Ada  MC68020  Run-Time  Reference  Manual  gives  information  on 
which  types  can  be  packed  as  components  of  composite  types,  as  'veil 
as  information  on  how  these  types  are  packed. 
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Chapter  13 

Representation  Clauses  and 
Implementation-Dependent 

Features 


Supplementary  XD  Ada  information  is  provided  for  Sections  13.1,  13.2, 
13.3,  13.4,  13.5,  13.5.1,  13.7,  13.7.1,  13.7.2,  13.7.3,  13.8,  13.9,  13.10.1 
and  13.10.2.  Two  additional  sections.  Section  13.7a  and  Section  13.9a, 
provide  XD  Ada  information  on  the  package  SYSTEM  and  on  the  XD 
Ada  import  and  export  pragmas. 


13.1  Representation  Clauses 

The  following  information  supplements  paragraphs  4  and  8: 

In  XD  Ada.  an  address  clause  can  only  apply  to  a  variable  or  a  single 
entry;  an  address  clause  cannot  apply  to  a  constant,  subprogram, 
pacluge,  or  task  unit.  See  Section  13.5  for  further  explanation. 

The  following  Information  supplements  paragraph  13: 

Pragma  PACK  is  implemented  in  XD  Ada.  As  the  behavior  of  pragma 
PACK  is  implementation  dependent,  users  are  advised  to  use  represen¬ 
tation  clauses  to  ensure  a  particular  representation  across  targets. 

In  XD  Ada,  all  array  and  record  components  are  aligned  on  byte 
boundaries  by  default;  the  effect  of  pragma  PACK  on  a  record  or 
array  is  to  cause  those  components  that  are  packable  to  be  allocated  in 
adjacent  bits  without  regard  to  byte  boundaries.  Whether  any  particular 
component  is  packable  depends  on  the  rules  for  its  type;  the  XD 
Ada  MC68020  Run-Time  Reference  Manual  gives  information  on  which 
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from  the  heap  as  needed,  until  all  heap  memory  is  exhausted  If  the 
value  is  less  than  zero,  the  exception  CONSTRAINT.ERROR  is  raised. 

The  following  information  supplements  paragraph  10: 

A  task  storage  specification  overrides  the  default  task  storage  size.  The 
specification  is  interpreted  as  follows.  If  the  value  of  the  expression 
is  greater  than  zero,  the  specified  size  is  rounded  up  to  the  nearest 
longword  boundary  (4  bytes),  and  this  determines  the  number  of 
storage  units  (bytes)  to  be  allocated  for  an  activation  of  the  task  of  the 
given  type.  In  the  absence  of  a  T’STORAGE.SIZE,  a  default  allocation 
is  used.  If  the  value  is  less  than  zero,  the  exception  CONSTRAINT, 
ERROR  is  raised. 

The  foilowring  information  supplements  paragraphs  8  and  10: 

NOTE 

The  XD  Ada  MC68020  Run-Time  Reference  Manual  discusses 
task  and  access  type  storage  and  storage  allocation  in  more 
detail. 

The  foUo%ving  information  supplements  paragraph  12: 

In  XD  Ada,  arbitrary  values  of  small  are  accepted.  The  default  value  of 
small  is  the  largest  power  of  two  that  is  not  greater  than  the  given  delta 
(see  Section  3.5.9). 

If  small  is  specified  (see  Section  3.5.9  (LRM)),  the  specified  value  must 
not  exceed  the  default.  For  example: 

(or  Hy_FIXE0‘ SHALL  un  0.001; 

This  example  is  a  legal  specification  for  the  declaration  of  MY.FIXED 
because  the  value  specified  for  small  (0.001)  is  less  than  the  delta  (0.1) 
and  that  also  satisfies  the  specified  range  (0.0. .1.0). 


13.3  Enumeration  Representation  Clauses 

The  following  information  supplements  paragraph  4: 

In  XD  Ada,  the  only  specific  restriction  on  enumeration  representation 
clauses  is  that  each  expression  for  an  integer  code  must  have  a  value  in 
the  range  MIN.INT  ..  MAX.INT. 
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13.4  Record  Representation  Clauses 


The  following  information  supplements  paragraph  4; 

For  statically  allocated  objects  and  for  objects  allocated  from  a  collection 
in  XD  Ada,  the  simple  expression  in  an  alignment  clause  must  be 
a  power  of  two.  The  upper  limit  is  2^’ ,  The  alignment  then  occurs 
at  a  location  that  is  a  number  of  bytes  times  the  value  of  the  simple 
expression:  a  value  of  2  causes  word  alignment,  a  v«ilue  of  4  causes 
longword  alignment,  and  so  on. 

Further  restrictions  apply  for  objects  declared  within  a  subprogram, 
where  XD  Ada  restricts  the  alignment  to  mod  1.  In  other  words,  stack- 
allocated  objects  can  only  be  byte  aligned. 

Bit-alignable  representation  clauses  are  provided  for  discrete  types, 
arrays  of  discrete  types,  and  record  types. 

See  the  XD  Ada  MC68020  Run-Time  Reference  Manual  for  information  on 
how  objects  are  allocated. 

The  following  information  supplements  paragraph  5; 

A  component  clause  specifics  the  storage  place  of  a  component  relative 
to  the  start  of  the  record.  In  XD  Ada  for  MC68020  targets,  the  sire  of  a 
storage  unit  (SYSTEM. STORAGE. UNIT)  is  eight  bits  (one  byte).  If  the 
number  of  bits  specified  by  the  range  is  sufficient  for  the  component 
subtype,  the  requested  size  and  placement  of  the  field  is  observed  (and 
overlaps  storage  boundaries  if  necessary);  otherwise,  the  specification  is 
illegal.  For  a  component  of  a  discrete  t^e,  the  number  of  bits  must  not 
exceed  32;  for  a  component  of  any  other  type,  the  size  must  not  exceed 
the  actual  size  of  the  component.  See  the  XD  Ada  MC68020  Run-Time 
Reference  Manual  for  information  about  determining  the  number  of  bits 
that  are  sufhcient  for  any  given  subtype. 

Component  values  in  XD  Ada  are  biased  when  a  component  clause 
requires  a  very  small  component  storage  space;  each  value  stored 
is  the  unsigned  quantity  formed  by  subtracting  COMPONENT. 
SUBTYPE 'FIRST  from  the  original  value.  See  the  XD  Ada  MC68020 
Run-Time  Reference  Manual  for  more  detailed  information. 

Component  clauses  in  XD  Ada  are  restricted  as  follows.  Any  com¬ 
ponent  that  is  not  packable  must  be  allocated  on  a  byte  boundary. 
Components  that  are  packable  can  be  allocated  without  restriction.  See 
the  XD  Ada  MC68020  Run-Time  Reference  Manual  for  a  definition  and 
description  of  packable  components. 
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The  following  information  supplements  paragraph  6: 

Components  named  in  a  component  clause  are  allocated  first;  then, 
unnamed  components  are  allocated  in  the  order  in  which  they  are 
written  in  the  record  type  declaration.  Variants  can  be  overlapped.  If 
pragma  PACK  is  specified,  packed  allocation  rules  (see  Section  13.1) 
are  used;  otherwise,  unpacked  allocation  is  used. 

The  following  information  supplements  paragraph  8: 

XD  Ada  generates  no  implementation-dependent  components  or 
names. 

The  following  information  supplements  the  Notes  section; 

The  example  of  record  representation  and  address  clauses  in  the 
Reference  Manual  for  the  Ada  Programming  Language  is  not  relevant  for 
XD  Ada  as  it  assumes  that  type  ADDRESS  is  represented  in  24  bits, 
whereas  in  XD  Ada  type  ADDRESS  is  represented  in  32  bits.  The 
following  example  is  appropriate  to  XD  Ada: 

ExampI*: 

typa  CONDI TION_CODe  !•  ( X, N, Z, V, C ) ; 

typ*  CONDITION_COOES  la  array  ( CONDlTION_CODB )  of  BOOLEAN; 
pra«aa  PACK  (CONDITION_CODBS ) ; 

typa  PROGRAM_3TATUS_WORD  la 

raeerd 


TRACE^BNABLE 

:  INTEGER  raaga  0  . .  3 

SUPERVISOR_STATE 

:  BOOLEAN; 

INTBRFUPT_iTATE 

:  BOOLEAN; 

inthrrupt’mask 

:  INTEGER  raaga  0  . .  7 

cc 

:  CONDITION  CODES; 

end  reeard; 

PROGRAM_STATUS_WORD  use 

record  at  mod  1; 

TRACE^ENABLE 

at  0  raaga  0  .  .  1  r 

supbrvisor_state 

at  0  raaga  2  ■.  2; 

INTERRUPT^itATE 

at  0  raaga  3  .  .  3 ; 

INTERRUPT^MASK 

at  0  raega  S  ■ ■  7 ; 

CC 

at  0  raaga  11  .  .  IS; 

aad  racord; 


tor  PROGRAM^STATUS^WORD' SIZE  uaa  2  *  SYSTEM. STORAGE^UNIT; 

Note  on  tha  axampla: 

The  record  representation  clause  defines  the  record  layout.  The  length 
clause  guarantees  that  exactly  two  storage  units  are  used. 
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Chapter  13 

Representation  Clauses  and 
Implementation-Dependent 

Features 


This  chapter  describes  XD  Ada  MC68020  Version  1.2  interrupt  handling. 
In  particular,  it  describes  the  handling  of  direct  interrupt  entries,  and 
use  of  pragma  DIRECT_ INTERRUPT. ENTRY. 


13.5.1  Interrupts 

The  following  infornution  supplements  all  of  this  section; 

Unlike  VAX  Ada,  XD  Ada  supports  interrupts.  The  address  in  the  use 
clause  is  the  address  of  the  interrupt.  The  address  is  interpreted  as  an 
offset  in  bytes  from  the  vector  base  renter.  For  details  of  MC68020 
exception  vector  assigrunents,  see  Table  6-2  of  the  MC68020  32-Bit 
Microprocessor  User's  Manual.  Note  that  when  assigning  vectors,  the 
offset  is  a  uiuldpte  of  four  of  the  vector  number.  In  this  way,  vector 
number  64  (decimal)  would  have  the  hexadecimal  offset  100. 

In  addition  to  support  for  normal  Ada  interrupt  entries,  XD  Ada 
provides  the  additional  pranas  LEVEL  and  DIRECT. INTERRUPT. 
OTTRY.  Pragma  LEVEL  is  given  for  a  task  type,  or  single  task  of  anony¬ 
mous  type,  and  gives  the  level  for  its  inter  apts.  Pragma  DIRECT. 
INTERRUIT'.ENTRY  is  used  to  connect  an  interrupt  entry  directly  to  the 
rec{uired  interrupt  vector,  and  is  described  below. 
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Component  Specification  Example: 

•ubtyp«  S  la  INTEGER  rang*  10  ..  13; 

typa  REC  1« 
racord 

X  I  S; 

Y  :  S; 

and  racord; 

for  REC  uaa 
racord 

X  at  0  raa^a  0  ..  3;  --  legal  because  4  bits 

are  sufficient 

Y  at  0  raaga  4  ..  4;  —  illegal  because  1  bit  is 

—  not  enough  to  represent 

—  an  integer  of  subtype  S 

aad  racord; 

Notea  on  the  example: 

The  subtype  declaration  in  this  example  implies  an  integer  with  a  min¬ 
imum  size  of  four  bits.  However,  the  components  X  and  Y  of  subtype 
S  are  biased  and  can  be  stored  in  only  two  Luts.  The  component  clause 
for  X  is  legal  because  it  requires  at  least  the  minimum  number  of  bits 
required  for  the  integer  subtype;  the  component  clause  for  Y  is  illegal 
because  it  does  not  allow  enough  bits  to  represent  the  integer  subtype. 


13.5  Address  Clauses 

The  following  information  supplements  paragraph  7; 

Like  VAX  Ada,  XD  Ada  supports  address  clauses. 

In  XD  Ada,  the  simple  name  must  be  the  name  of  a  variable.  XD  Ada 
does  not  allow  address  clauses  that  name  constants;  or  subprogram, 
package,  or  task  units. 

An  intermediate  pointer  is  created  only  if  the  resulting  address  is  not  a 
compile-time  constant. 

The  placement  of  an  address  clause  in  XD  Ada  must  follow  the  rules 
given  in  Section  13.1.  In  other  words,  the  clause  and  the  variable 
declaration  must  both  occur  immediately  within  the  same  declarative 
part  or  package  specification,  and  the  declaration  must  occur  before 
the  clause.  The  restrictions  for  forcing  occurrences  also  apply;  with 
respect  to  address  clauses,  any  occurrence  of  the  variable  name  after  its 
declaration  is  a  forcing  occurrence. 
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Address  clauses  are  not  allowed  in  combination  with  any  of  the  XD  Ada 
pragmas  for  importing  or  exporting  objects.  If  used  in  such  cases,  the 
pragma  involved  is  ignored. 

The  following  information  supplements  the  Notes  section: 

Also,  if  an  address  clause  is  specified  for  an  object  of  a  type  that  has 
been  declared  with  an  alignment  clause,  the  alignment  required  for  the 
address  is  checked  against  the  alignment  given  for  the  record  type.  If 
the  two  are  incompatible,  the  exception  PROGRAM.ERROR  is  raised. 

The  same  check  applies  to  a  type  that  contains  a  component  of  a  type 
that  has  been  declared  with  an  alignment  clause  (the  alignment  of  the 
component  forces  the  alignment  of  the  containing  type). 


13.5.1  Interrupts 

The  following  information  supplements  all  of  this  section: 

Unlike  VAX  Ada,  XD  Ada  supports  interrupts.  The  address  in  the  use 
clause  is  the  address  of  the  interrupt.  The  address  is  interpreted  as  an 
offset  from  the  vector  base  register. 

XD  Ada  provides  the  additional  pragma  LEVEL.  This  pragma  is  given 
for  a  task  type,  or  single  task  of  anonymous  type,  and  gives  the  level  for 
its  interrupts. 

There  are  two  ways  an  interrupt  entry  can  be  handled,  according  to 
whether  or  not  the  task  has  a  pragma  LEVEL.  The  XD  Ada  MC68020 
Run-Time  Reference  Manual  gives  examples  of  interrupt  handlers. 

Tasks  with  interrupt  entries  but  no  pragma  run  at  interrupt  level  whilst 
accepting  an  interrupt  in  a  rendezvous.  Other  interrupts  of  the  same 
level  or  lower  levels  are  inhibited.  It  is  possible  to  lose  interrupts  with 
this  method. 

Tasks  with  interrupt  entries  and  a  pragma  LEVEL  always  run  at  interrupt 
level,  whether  inside  or  outside  a  rendezvous.  This  enables  the  user  to 
avoid  losing  interrupts. 

An  interrupt  entry  to  a  task  with  the  pragma  behaves  like  an  ordinary 
entry  call.  An  interrupt  entry  to  a  task  with  no  pragma  behaves  like  a 
conditional  entry  call.  If  there  is  an  accept  statement  waiting  for  the 
interrupt,  the  body  of  the  accept  statement  is  executed  immediately. 
When  the  body  is  complete,  the  task  is  inserted  in  the  ready  queue 
and  the  interrupt  completed  by  a  retum-from-interrupt  instruction.  The 
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A  record  component  that  begins  a  variant  is  always  allocated  on  the  next 
byte,  word  or  long-word  according  to  its  type,  a  variant  that  begins  on 
other  than  its  default  can  be  obtained  only  with  a  record  representation 
clause. 

XD  Ada  provides  no  additional  representation  pragmas 


1 3.7  The  Package  System 

The  following  information  replaces  the  MC68020  supplement  to  para¬ 
graph  5: 

In  XD  Ada  MC68000,  the  enumeration  literal  for  SYSTEM  NAME  is 
MC68000. 

The  following  information  replaces  the  MC68020  supplement  to  para¬ 
graph  9: 

'  In  XD  Ada  MC68000,  the  number  given  for  MEMORY_SIZE  must  be 

2**24.  Like  VAX  Ada,  XD  Ada  MC68000  does  not  provide  support  for 
checking  or  ensuring  that  the  given  size  is  not  exceeded. 


1 3.7a  XD  Ada  Additions  to  the  Package  SYSTEM 

13.7a.1  Properties  of  the  Type  ADDRESS 

In  XD  Ada  MC68000,  ADDRESS  is  a  private  type  redefined  as  follows: 

tfp*  ADDRBSS_ItlT  !•  rmnf  0  ..  MEMORY_SI2E  -  1: 
for  AOORESS_TtlT’SIZE  uoo  32  j 


13.7.1  System-Dependent  Named  Numbers 

In  XD  Ada  MC68000,  the  value  for  the  system-dependent  named 
number,  TICK,  is  redefined  as  folloivs: 


Attribute 

MC68000 

TICK 

1.0  X  2*'' 
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accept  statement  can  make  excursions  into  other  routines,  and  can  even 
make  entry  calls,  but  must  not  suspend  the  task  before  the  interrupt 
is  dismissed,  otherwise  the  program  repeatedly  services  the  interrupt 
unsuccessfully. 

Writing  interrupt  handlers  in  XD  Ada  requires  detailed  knowledge  of 
the  behavior  of  the  target  computer's  interrupt  system.  It  is  not  possible 
simply  to  place  a  use  clause  on  an  entry  to  achieve  the  desired  effect. 


13.7  The  Package  System 

The  following  information  supplements  paragraph  1: 

XD  Ada  additions  to  the  package  SYSTEM  are  described  in  Section 
13.7a. 

The  following  information  supplements  paragraph  5: 

In  XD  Ada,  the  enumeration  literal  for  SYSTEM_NAME  is  MC68020. 
The  following  information  supplements  paragraph  7: 

In  XD  Ada,  the  value  given  for  STORAGE, UNIT  must  be  8  (bits). 

The  following  information  supplements  paragraph  9: 

In  XD  Ada,  the  number  given  for  MEMORY.SIZE  must  be  2*  *31-1. 
Like  VAX  Ada,  XD  Ada  does  not  provide  support  for  checking  or 
ensuring  that  the  given  size  is  not  exceeded. 

The  following  information  supplements  paragraph  11: 

As  with  VAX  Ada,  XD  Ada  imposes  no  further  limitations  on  these 
pragmas.  To  reduce  the  amount  of  recompilation  required,  XD  Ada 
identifies  those  uitits  that  have  a  real  dependence  on  the  values  affected 
by  these  pragmas;  only  such  units  must  be  recompiled.  In  particular, 
predefined  XD  Ada  packages  do  not  depend  on  the  values  affected  by 
these  pragmas,  and  none  require  recompilation  if  these  pragmas  are 
used 


1 3.7a  XD  Ada  Additions  to  the  Package  SYSTEM 

In  addition  to  the  language-required  declarations  in  package  SYSTEM, 
XD  Ada  declares  the  operations,  constants,  types,  and  subtypes  de¬ 
scribed  in  the  following  sections. 
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13.7a. 1  Properties  of  the  Type  ADDRESS 


In  XD  Ada,  ADDRESS  is  a  private  type  for  which  the  following  opera¬ 
tions  are  declared: 


Address  type 


type  ADDRESS  Is  priests; 

ADDRESS  ZERO  i  cosstsat  ADDRESS; 


type  ADDRESS_INT  is  rsspe  MIN_INT  ..  MAJC_INT; 


fsaettes  TO_AODRESS 
fsaetlea  T0~ADDRESS 
(uaeties  T0~ ADDRESS_ I NT 


(X  «  ADDRESS_INT) 

(X  t  <universal_integer ) ) 
(X  I  ADDRESS) 


retura  ADDRESS; 
return  ADDRESS; 
return  ADDRESS_INT; 


funetien 

fnnetlen 

fnaetlen 

(nnetien 


•+■  (LEFT  t 
■+■  (LEFT  : 

(LEFT  I 
*-■  (LEFT  I 


ADDRESS; 

ADDRESS_INT; 

addrbssT 

ADDRESS; 


RIGHT  s  ADDRBSS_INT)  return  ADDRESS; 
RIGHT  :  ADDRESS)  return  ADDRESS; 

RIGHT  I  ADDRESS)  return  ADDRESS.INT; 

RIGHT  i  ADDRESS_IHT)  return  ADDRESS? 


(nnntion 

(LEFT, 

RIGHT 

fnnntian 

(LEFT, 

RIGHT 

(anotian 

•<• 

(LEFT, 

RIGHT 

(unatiun 

(LEFT, 

RIGHT 

funatinn 

•>“ 

( LEFT, 

RIGHT 

(unetinn 

(LEFT, 

RIGHT 

I  ADDRESS)  return  BOOLEAN; 
I  ADDRESS)  return  BOOLEAN; 
I  ADDRESS)  retnm  BOOLEAN; 
t  ADDRESS)  return  BOOLEAN; 
t  ADDRESS)  return  BOOLEAN; 
>  ADDRESS)  return  BOOLEAN; 


Note  that  becauee  ADDRESS  la  a  private  type 
the  functiona  and  are  already  available 


--  Generic  functiona  uaed  to  acceaa  memory 

feaerie 

type  TARGET  la  private; 

(nnetien  FETCH_FRO«_ ADDRESS  (A  i  ADDRESS)  retum  TARGET; 

fenerie 

type  TARGET  iu  private; 

precedure  ASSIGN_TO_ADDRESS  (A  ■  ADDRESS;  T  ■  TARGET); 

The  addition,  subtraction,  and  relational  functions  provide  arithmetic 
and  comparative  operations  for  addresses.  The  generic  subprograms 
FETCH_FROM_ADDRESS  and  ASSIGN.TO. ADDRESS  provide  op¬ 
erations  for  reading  from  or  writing  to  a  given  address  interpreted  as 
having  any  desired  type.  ADDRESS, ZERO  is  a  deferred  constant  whose 
value  corresponds  to  the  first  (machine)  address. 
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In  an  instantiation  of  FETCH_FROM_ADDRESS  or  ASSIGN_TO_ 
ADDRESS,  the  actual  subtype  corresponding  to  the  formal  type  T 
must  not  be  an  unconstrained  array  type  or  an  unconstrained  type  with 
discriminants.  If  the  actual  subtype  is  a  type  with  discriminants,  the 
value  fetched  by  a  call  of  a  function  resulting  from  an  instantiation  of 
FETCH_FROM_ADDRESS  is  checked  to  ensure  that  the  discriminants 
satisfy  the  constraints  of  the  actual  subtype.  In  any  other  case,  no  check 
is  made. 

ExampI*: 

X  :  INTEGER; 

A  I  SYSTEM. ADDRESS  X'ADDRESS;  --  legal 

fuaetiaa  FETCH  la  aa«  FBTCH_FROM_ADDRESS( INTEGER) ; 
precaaara  ASSIGN  la  aaw  ASSiaN_TO_AODRESS( INTEGER) ; 

X  I-  FETCH(A);  —  like  ’X  i-  A. all;' 

ASSIGN(A,X):  —  li)te  'A. all  i-  X;' 


13.7a.2  Type  Class  Enumeration  Type 

XD  Ada  declares  the  following  enumeration  type  for  identifying  the 
various  Ada  type  classes: 

type  TYPE_CLASS  la  (TYPE_CLASS_ ENUMERATION, 

TYPE_CIJVSS_  INTEGER, 

TYPE_CLASS_FIXED_POINT, 

T  YPe”c  LAS  s”  float!  NG_  PO I  NT , 

TYPE^CLASS" ARRAY, 
type^class'record , 

TYPe'cLASS* ACCESS , 

typeIclass'task, 
typeIclass“address ) ; 

In  addition  to  the  usual  operations  for  discrete  types  (see  Section  3.5.5), 
XD  Ada  provides  the  attribute  TYPE.CLASS. 

For  every  type  or  subtype  T: 

T' TYPE.CLASS  Yields  the  value  of  the  type  class  for  the  full  type  of 
T.  If  T  is  a  generic  formal  type,  then  the  value  is  that 
for  the  corresponding  actual  subtype.  The  value  of 
this  attribute  is  of  the  type  TYPE.CLASS. 

This  attribute  is  only  allowed  if  its  unit  names  the  predefined  package 
SYSTEM  in  a  with  clause 
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Examples: 

Given 

typa  Hy_INT  is  rang*  1..10; 
typ*  NBW_INT  la  aaw  STRING; 
packag*  PACK  is 

PRIV  ia  privata; 

privata 

tfpa  PR IV  ia  aaw  FLOAT; 
aad  PACK; 

then 

—  MY_INT'TYPE_CLASS  equals  TYPE_CLASS  INTEGER 

—  NEW_INT'TYPE_C::ASS  equals  TYPE_CLASS~ARRAY 

—  PRIVTYPE_CLASS  equals  TYPB_CLASS_FLOATING  POINT 


13.7a.3  Hardware-Oriented  Types  and  Functions 

XD  Ada  declares  the  following  types,  subtypes,  and  functions  for 
convenience  in  working  with  MC68020  hardware-oriented  storage: 

XD  Ada  hardware-oriented  types  and  functions 

typ*  BIT_ARRAY  la  array  (INTEGER  rang*  <>)  of  BOOLEAN; 
pragM  PACK(  BIT_ARRAy ) ; 

s«btyp*  BIT_ARRAY_8  la  BIT_ARRAY  (0  ..  7); 

a«Myp*  BItIaRRAyIiS  la  BIT_ABRAY  (0  ..  15); 
amhtyp*  BIt3aRRAY_32  ia  BIT_ARRAY  (0  ..  31); 
aabtyp*  BIT'ARRAY^fil  ia  aiT_ARRAY  (0  ..  63); 
typ*  UNSIGMiD_BYTe  ia  rang*  0  ..  255; 
fer  UMStONBD'BYTE'SIZB  aae  8; 

(aaetiee  ‘not*  (LBP-r  i  UNSIGNeD_BYTB)  retam  UNSIGNBD.BYTB; 

(aaetiee  'and*  (LEFT,  RIGHT  t  UNSiaNEO~BYTE)  retam  UNSIGNEo'bYTB; 

(aaetiee  -or"  (LBPT,  RIGHT  :  ONSIGNBO^BYTE)  retam  UNSIGNEd'bYTB; 

(aaetiee  ’xor’  (LEFT,  RIGHT  i  UNSIGNEd'bYTE)  retam  UNSIGNED^BYTE; 

(aaetiee  T0_UNSIGNED_BYTE  (X  s  BIT_ARRAY_8)  mtum  UNSIGNED_BYTE; 

(aaetiee  To'bIT_ARBAY_8  (X  :  UNSIGNED.BYTE )  retam  B1T_ARRAY_8; 

typ*  UNSIGNED_BYTE_ARRAY  ia  array  (INTEGER  rang*  <>)  e(  UNSIGNED_8YTE ; 
typ*  UNSIGNED^HORD  ia  rang*  0  ..  65535; 

(ar  UNSIGNBd'woRD'SIZE  vs*  16; 

(aaetiea  "not"  (LEFT  i  lINSIGNED_HORD)  return  UNSIGNED_WORD: 

(naetiaa  'snd*  (LEFT,  RIGHT  ;  UNSIGNED_HORD)  mtum  UN5IGNED~H0R0; 

(aaetiaa  *or*  (LEFT,  RIGHT  r  UNSIGNED_W0RD)  ratam  UNSIGNEd'worD; 

(aaetiaa  "xor'  (LEFT,  RIGHT  i  UNSIGNED^horD)  mtum  UNSIGNEd'hord; 

(aaetiea  T0_UNSIGNED_H0RD  (X  i  BIT_ARRAY_ 16 )  return  UNSIGNED_W0RD: 

(aaetiea  To2bIT_ABRAY_16  (X  :  UNSIGNED_HORD )  return  BIT_ARRAY_ 16 ; 
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UNSIGNED_V#ORD_ARRAY  la  array  (INTEGER  raaga  <>)  of  UNSIGNED  WORD; 


typa  UNSIGNED_LONGWORO  la  raago  MIN_INT  ..  MAX  INT; 
for  UNSIGNED_L0NGW0RD'SI2E  uaa  J2; 

*■■***'•■  "not"  (LEFT  :  UNSIGNED_LONGHORD)  ratura  UNSIGNED  LONGWORD; 

*“***i®o  "and"  (LEFT,  RIGHT  i  UNS1GNBD_L0NGW0RD )  ratura  UNSIGNED  LONGWORD: 

*““®*^*“  "or"  (LEFT,  RIGHT  i  UNS I GNED_ LONGWORD)  ratura  UNSIGNED  LONGWORD; 

*»we*laa  "xor"  (LEFT,  RIGHT  :  UNSIGNED_LONGWORD)  ratura  UNSIGNED~LONGWORD; 

*'**«*i*a  TO_ONSIGNED_LONGWORD  (X  :  BlT_ARRAy  32)  ratura  Ui:siGNED  LONGWORD; 
(aaetlOB  TO_BIT_ARRAY_32  (X  i  l'NSIGNED_WORD ) 'ratura  BIT_ARRAY  32; 

*TP*  UNSIGNBD_L0NGW0RD_ARRAY  la  array  (INTEGER  raaga  <>)  of  UNSIGNED  LONGWORD; 


13. 7a. 4  Convantional  Namaa  for  Unsigned  Longwords 


The  following  XD  Ada  declarations  provide  conventional  names  for 
static  subtypes  of  the  predefined  type  UNSIGNED. LONGWORD: 


aaktyya 

UNSIGNED. 

1 

la 

UNSIGNED 

LONGWORD 

0  . 

.  2* 

1-1; 

aakty»a 

UNSIGNED. 

2 

la 

unsigned  LONGWORD 

0  . 

.  2* 

2-1; 

anbtyya 

UNSIGNED 

3 

la 

UNSIGNED 

LONGWORD 

0  . 

.  2* 

3-1; 

aabtfiya 

UNSIGNED 

4 

la 

UNSIGNED 

LONGWORD 

0  . 

.  2* 

4-1; 

aabty^ 

UNSIGNED. 

5 

la 

UNSIGNED  LONGWORD 

0  . 

.  2* 

5-1; 

aabtyga 

UNSIGNED. 

6 

la 

UNSIGNED 

LONGWORD 

0  . 

.  2* 

6-1; 

aabty^ 

UNSIOIED. 

7 

la 

UNSIGNED 

LONGWORD 

ru9« 

0  . 

.  2* 

7-1; 

aabtypa 

UNSIGNED. 

8 

la 

UNSIGNED  LONGWORD 

0  . 

.  2* 

8-1 

aabtypa 

UNSIGNED.S 

la 

UNSIGNED  LONGWORD 

0  . 

.  2* 

9-1 

aabtypa 

UNSIGNED. 

10 

la 

UNSIGNED 

LONGWORD 

rug# 

0  . 

.  2* 

10-1 

aabtyiF* 

UNSIGNED. 

U 

la 

UNSIGNED  LONGWORD 

0  . 

.  2* 

11-1 

aabtypo 

UNSIGNED 

12 

la 

UNSIGNED  LONGWORD 

ruf« 

0  . 

.  2» 

12-1 

aabtyga 

UNSIGNED. 

13 

la 

UNSIGNED  LONGWORD 

rMif« 

0  . 

.  2* 

13-1 

aabtyi^ 

UNSIGNED. 

14 

la 

UNSIGNED  LONGWORD 

tmmff 

0  . 

.  2* 

14-1 

aabtyya 

UNSIGNED. 

IS 

la 

UNSIGNED 

LONGWORD 

rmm^m 

0  . 

.  2» 

15-1 

aabtyfo 

UNSIGNED. 

16 

la 

UNSIGNED. 

LONGWORD 

ruf* 

0  . 

.  2* 

16-1 

aabtypo 

UNSIGNED. 

17 

la 

UNSIGNED 

LONGWORD 

ruif# 

0  . 

.  2* 

17-1 

aabtypo 

UNSIGNED. 

18 

la 

UNSIGNED 

LONtnrCRD 

raaff* 

0  . 

.  2‘ 

18-1 

aabtypo 

UNSIGNED. 

19 

la 

UNSIGNED. 

LONGWORD 

0  . 

.  2* 

19-1 

aabtypo 

UNSIGNED. 

20 

la 

UNSIGNED 

L(3NGWORD 

raafa 

0  . 

.  2* 

20-1 

aabtypo 

UNSIGNED. 

21 

la 

UNSIGNED 

LONGWORD 

raafa 

0  . 

.  2* 

21-1 

aabtypo 

UNSIGNED. 

22 

la 

UNSIGNED 

LONGWORD 

raaya 

0  . 

.  2* 

22-1 

aabtypo 

UNSIGNED 

23 

la 

UNSIGNED 

LONGWORD 

raaga 

0  . 

.  2* 

23-1 

aabtypo 

UNSIGNED. 

24 

la 

UNSIGNED 

LONGWORD 

raaga 

0  . 

.  2* 

24-1 

aabtypo 

UNSIGNED 

25 

la 

UNSIGNED 

LONGWORD 

raaga 

0  . 

.  2* 

25-1 

aabtypo 

UNSIGNED 

26 

la 

UNSIGNED 

LONGWORD 

raaga 

0  . 

.  2* 

26-1 

aabtypo 

UNSIGNED 

27 

la 

UNSIGNED 

LONGWORD 

raaga 

0  . 

.  2’ 

27-1 

aabtypo 

UNSIGNED 

28 

la 

UNSIGNED 

LONGWORD 

raaga 

0  . 

.  2* 

28-1 

aabtypo 

UNSIGNED. 

29 

la 

UNSIGNED  LONGWORD 

raaga 

0  . 

.  2* 

29-1 

aabtypo 

UNSIGNED. 

30 

la 

UNSIGNED 

LONGWORD 

raaga 

0  . 

.  2* 

30-1 

aabtypo 

UNSIGNED. 

31 

la 

UNSIGNED. 

LONGWORD 

raaga 

0  . 

.  2* 

31-1 
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13.7.1  System-Dependent  Named  Numbers 


In  XD  Ada,  the  values  for  system-dependent  named  numbers  are  as 
shown  in  the  following  table. 


Attribute 

MC6M20 

MINJNT 

-2^' 

MAXJNT 

2^'-l 

MAX.DIGITS 

18 

MAX.MANTISSA 

31 

FINE.DELTA 

2.0'^' 

TICK 

162.5  X  10-‘ 

13.7.2  Representation  Attributes 

The  foUoiving  infomution  suppicmentt  all  of  thla  section: 

For  any  object,  program  unit,  label,  or  entry  X; 

X '  ADDRESS  Yields  the  address  of  the  first  of  the  storage  ele¬ 

ments  allocated  to  X.  For  a  subprogram,  package, 
task  unit  or  label,  this  value  refers  to  the  machine 
code  associated  with  the  corresponding  body  or 
statement.  For  an  entry  for  which  an  address 
cbuse  has  been  given,  the  value  refers  to  the  offset 
of  the  interrupt  vector  from  the  vector  base  register. 
The  value  of  this  attribute  is  of  the  type  ADDRESS 
defined  in  the  package  SYSTEM. 

For  an  object  that  is  a  variable,  the  value  is  the  ac¬ 
tual  address  of  the  variable  (which  may  be  statically 
or  dynamically  allocated),  lliis  attribute  forces  a 
variable  to  be  allocated  in  memory  rather  than  in 
a  register,  and  causes  the  variable  to  be  marked  as 
volatile  for  the  duration  of  the  block  statement  or 
body  containing  use  of  the  attribute.  If  the  location 
of  the  variable  is  not  byte-aligned,  the  value  is 
the  address  of  the  lowest  byte  that  contains  the 
variable.  For  an  object  that  is  a  constant,  the  value 
is  the  address  of  the  constant  value  in  memory; 
however,  two  occurrences  of  C' ADDRESS,  where 
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C  denotes  a  constant,  may  or  may  not  yield  the 
same  address  value  Fjr  an  object  that  is  a  named 
number,  the  value  is  zero  (ADDRESS_ZERO). 

NOTE 

In  the  context  of  these  representation 
attributes,  ADDRESS_ZERO  means  only 
that  no  useful  interpretation  of  a  nonzero 
value  is  currently  supported.  That  is,  its 
use  as  a  result  of  C' ADDRESS  is  subject 
to  change. 

For  an  access  object,  X. all' ADDRESS  is  the  address 
of  the  designatecl  object;  X.all'ADDRESS  is  subject 
to  an  ACCESS.CHECK  for  the  designated  object. 
For  a  record  component,  X.C' ADDRESS  is  subject 
to  a  DISCRIMINANT.CHECK  for  an  object  in 
a  variant  part.  For  an  array  component  or  slice, 
X(l)' ADDRESS  or  Xai  . 12)' ADDRESS  is  subject  to 
an  INDEX.CHECK  for  the  denoted  component  or 
slice. 

For  program  units  that  are  task  units  or  package 
units,  the  value  is  zero  (ADDRESS.ZERO).  For 
program  units  that  are  subprograms,  the  value  is 
the  same  as  the  address  that  would  be  exported. 
(See  Section  13. 9a.  1.4  (LRM)  for  information  on 
pragmas  EXPORT  FUNCTION  and  EXPORT 
PROCEDURE). 

For  entries,  the  value  is  zero  (ADDRESS.ZERO). 

For  labels,  the  value  is  the  address  of  the  machine 
code  which  follows  the  label. 

For  any  type  or  subtype  X,  or  for  any  object  X: 

X'SIZE  For  a  type  or  a  subtype,  the  value  is  limited  to 

values  in  the  range  0  . .  MAX.INT;  the  exception 
NUMERIC.ERROR  (see  Section  11.1)  is  raised  for 
values  outside  this  range.  For  an  object  that  is  a 
variable  or  a  constant  in  XD  Ada,  the  value  is  its 
size  in  bits.  For  an  object  that  is  a  named  num¬ 
ber,  the  value  is  zero.  For  a  record  component, 
X.C 'SIZE  is  subject  to  a  DISCRIMINANT.CHECK 
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for  an  object  in  a  variant  part.  For  an  array  compo¬ 
nent  or  slice,  X(I)'SIZE  or  X(I1..I2)'SIZE  is  subject 
to  an  INDEX_CHECK  for  the  denoted  component 
or  slice. 

For  any  type  or  subtype  X: 

X '  MACHINE_SIZE  Yields  the  number  of  machine  bits  to  be  allocated 
for  variables  of  the  type  or  subtype.  This  value 
takes  into  account  any  padding  bits  used  by  XD 
Ada  when  allocating  a  variable  on  a  byte  boundary. 
The  value  of  this  attribute  is  of  the  type  universal_ 
integer. 

The  value  is  always  a  multiple  of  8  (bits).  In  partic¬ 
ular,  for  discrete  types  it  is  8,  16,  or  32.  The  value 
is  limited  to  the  range  O..MAX_INT;  the  exception 
NUMERIC_ERROR  is  raised  for  values  outside  this 
range. 

For  any  object  X: 

X '  BIT  Yields  the  bit  offset  within  the  storage  unit  (byte) 

that  contains  the  first  bit  of  the  storage  allocated  for 
the  object.  The  value  of  this  attribute  is  of  the  type 
unixxr^Jnteger,  and  is  always  in  the  range  0..7. 

For  an  object  that  is  a  variable  or  a  constant  al¬ 
located  in  a  register,  the  value  is  zero.  (The  use 
of  this  attribute  does  not  force  the  allocation  of 
a  variable  to  memory.)  For  an  object  that  is  a 
formal  parameter,  this  attribute  applies  either 
to  the  matching  actual  parameter  or  to  a  copy 
of  the  matching  actual  parameter.  For  an  ac¬ 
cess  object,  the  value  is  zero  (in  the  absence  of 
CONSTRAJNT.ERROR),  X.aU'BrT  is  subject  to 
an  ACCESS.CHECK  for  the  designated  object. 

For  a  record  component,  X.C'BIT  is  subject  to 
a  DISCRIMINANT.CHECK  for  a  component  in 
a  variant  part.  For  an  array  component  or  slice, 
X(l)'Brr  or  X(11..12)’BIT  is  subject  to  an  1NDEX_ 
CHECK  for  the  denoted  component  or  slice. 
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The  following  information  supplements  the  Notes  section: 

The  attribute  X'MACH1NE_SIZE  gives  the  size  that  would  be  used  for 
a  variable  of  the  type  or  subtype;  it  does  not  give  the  size  that  may  be 
used  for  a  component  of  that  type  or  subtype. 

The  machine  size  of  a  t)^e  or  subtype  can  be  influenced  by  representa¬ 
tion  clauses,  uidike  the  size  of  a  tj'pe  or  subtype,  which  is  independent 
of  representation  clauses.  The  machine  size  of  a  base  type  can  be  less 
than,  equal  to,  or  greater  than  the  size  of  that  same  base  type.  See  the 
XD  Ada  MC68Q20  Run-Time  Reference  Manual  for  examples  and  additional 
discussion. 


13.7.3  Representation  Attributes  of  Reai  Types 

The  following  information  supplements  paragraphs  3  and  4: 

For  both  fixed-  and  floating-point  types: 

T'MACHINE.ROUNDS  In  XD  Ada  this  value  is  FALSE 

T'MACHINE.OVERFLOWS  In  XD  Ada  this  value  is  FALSE 

The  XD  Ada  values  of  the  other  representation  attributes  for  floating¬ 
point  types  are  dependent  on  the  floating-point  type  and  are  listed  in 
Appendix  F. 


1 3.8  Machine  Code  Insertions 

The  fallowing  information  supplements  paragraph  4: 

XD  Ada  provides  the  package  MACHINE.CODE.  Machine  code  inser¬ 
tions  can  be  expanded  in  line. 

This  predefined  package  and  not  a  user-defined  package  must  be 
nam^  in  a  with  clause  that  applies  to  the  compilation  unit  in  which  the 
code  statement  occurs. 

The  following  is  an  example  of  MACHINE_CODE  and  the  with  clause 
in  use: 
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—  A  machine  code  procedure  to  evaluate  the  sine  and  cosine  of 

—  parameter  X,  returning  the  results  in  parameters  Y  and  Z 

—  respectively;  the  procedure  is  to  be  expanded  in  line,  so 

—  it  does  not  require  a  stack  frame  of  its  owni 
with  NACHINB_COOB; 

precednre  SINCOSl  (  Xt  la  FLOAT; 

Y:  out  FLOAT; 

Zt  out  FLOAT  )  Is 
use  HACHINE_CODe; 
be«la  FSINCOS_REG_INST'  ( 

OPCODE  ->  rSINCOS, 

SOURCB_REGISTER  ->  FPO, 

SIN_RBGISTBR  ->  FPl, 

COs"rEGISTER  ->  FP2  ); 


ead  SINCOSl; 

XD  Ada  provides  the  pragma  CALL_SEQUENCE_PROCEDURE  which 
specifies  parameter-passing  mechanisms  for  machine  code  procedures, 
llie  prag^  is  dedned  in  Appendix  B.  Examples  of  machine  code 
insertion  are  given  in  Section  6.1  of  the  XD  Ada  MC6S020  Run-Time 
Reference  Manual.  For  the  specitication  of  the  package  MACHINE. 
CODE,  see  Appendix  B  of  the  XD  Ada  MC68020  Run-Time  Referetux 
Manual. 


1 3.9  Interface  to  Other  Languages 

The  following  information  supplements  paragraph  4: 

As  with  VAX  Ada,  use  of  pragma  INTERFACE  in  XD  Ada  is  interpreted 
as  being  equivaient  to  supplying  the  body  of  the  named  subprogram  or 
subprograms.  Therefore,  the  following  rules  apply: 

•  If  a  subprogram  body  is  given  later  for  a  subprogram  named  with 
pragma  INTERFACE,  the  body  is  illegal. 

•  If  pragma  INTERFACE  names  a  subprogram  body,  the  pragma  is 
illegal. 

•  If  a  duplicate  pragma  INTERFACE  is  given,  the  latter  pragma  is 
illegal. 

In  XD  Ada,  pragma  INTERFACE  applies  to  a  renaming  only  if  the 
renaming  occurs  in  the  same  declarative  part  or  package  specification 
as  the  pragma.  The  renamed  subprogram  must  also  occur  in  that  same 
declarative  part  or  package  specitication;  renamed  subprograms  that 
occur  outside  the  declarative  part  or  package  specification  are  ignored 
(without  a  wanting  diagnostic). 
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In  addition,  XD  Ada  interprets  the  effect  of  pragma  INTERFACE  in  such 
a  way  that  it  accepts  and  ignores  implicit  declarations  of  subprograms 
(such  as  predefined  operators,  derived  subprograms,  attribute  functions, 
and  so  on). 

Dependent  upon  its  use  in  an  XD  Ada  program,  pragma  INTERFACE  is 
interpreted  in  combination  with  one  of  two  XD  Ada  import  subprogram 
pragmas:  IMPORT.FUNCTION  or  IMPORT.PROCEDURE.  These 
pragmas  are  d^'scribed  in  Section  13.9a.  1. 

The  language  name  is  ignored,  and  so  may  be  any  identifier  that 
suggests  the  language,  source,  or  nature  of  the  imported  subprogram. 

If  pragma  INTERFACE  is  used  without  one  of  these  import  pragnu  .,  a 
default  interpretation  is  used,  as  follows: 

•  If  the  subprogram  name  applies  to  a  single  subprogram,  then  a 
default  import  pragma  is  assumed  as  follows: 

For  a  function,  the  default  is  as  follows: 

prafM  IMPORT_FUNCTION  <  f  unction_daalqnator ) ; 

For  a  procedure,  the  default  is  as  follows: 

prafa  IMFORT.PROCBDURX  ( procedure_ldentlf  ler ) ; 

•  If  the  subprogram  name  applies  to  two  or  more  subprograms,  the 
pragma  applies  to  all  of  them.  However,  a  warning  is  given  if  the 
appropriate  XD  Ada  import  pragmas  are  not  given  for  all  of  the 
subprograms. 

Whether  or  not  pragma  INTERFACE  is  used  with  an  import  pragma,  the 
subprogram  name  must  be  an  identiher,  or  a  string  literal  that  denotes 
an  operator  symbol.  In  the  following  example,  pragma  INTERFACE 
specifies  that  the  indicated  routines  SQRT  and  EXP  are  to  be  imported 
and  used  as  bodies  for  the  XD  Ada  functions  SQRT  and  EXP  in  package 
FORT.UB: 

aaeka«a  FORT.LIB  la 

faaettea  SQRT(X  i  BLOAT)  raton  FLOAT; 
faaettoB  SXP(X  i  FLOAT)  ratura  FLOAT; 
prlvata 

pra^M  I  NTBRFACB(  FORTRAN,  SQRT); 
pra«M  INTERFACE  (FORTRAN,  EXP); 
aa4  FORT_LIB; 


13-1t 


Interlace  to  Other  Languages 


13.9 


The  following  information  supplements  paragraph  5: 

In  XD  Ada,  the  example  package  FORT. LIB  is  interpreted  as  follows; 
pragma  INTERFACE  specifies  that  the  indicated  routines  SQRT  and 
EXP  are  to  be  imported  and  used  as  bodies  for  the  Ada  functions  SQRT 
and  EXP  in  package  FORT.UB. 

paekaa*  CHOOSB.R  la 

proeadara  P(X  ■  INTEGER); 
praeadara  P(X  <  FLOAT); 

private 

praeadara  R(X  t  FLOAT)  raaaaaa  P; 
pra«u  INTERFACE  (ASSEMBLER,  R); 
aad  CHOOSB.R; 

In  this  example,  pragma  INTERFACE  indicates  that  the  body  for  the 
second  procedure  P  is  to  be  imported  as  routine  R. 

The  following  Information  supplements  the  Notes  section: 

The  meaning  of  the  subprogram  name  is  determined  as  for  any  name 
(see  Section  8.3  (LRM)),  except  that  the  name  can  denote  more  than  one 
subprogram.  Thus,  in  the  following  declaration  the  pragma  INTERFACE 
applies  to  the  Brst  two  procedures;  it  does  not  apply  to  the  third 
because  the  declaration  is  not  visible  at  the  place  of  the  pragma. 

proeadarv  P  (Bt  BOOLEAN); 
pro««dar«  P  (It  INTEGER); 
pragaa  INTERFACE  (ASSEMBLER,  P); 
preeadar*  P  (Ft  FLOAT); 

This  same  interpretation  is  made  for  pragmas  used  to  import  and  export 
subprograms  (see  Section  13.9a. 1). 

If  pragma  INTERFACE  and  pragma  INLINE  are  used  together,  the 
pragnna  INLINE  is  ignored  regardless  of  the  order  in  which  the  two 
pragmas  appear. 

Refer  to  Chapter  3  of  the  XD  Aria  MC68020  Run-Time  Reference  Manual 
for  subprogram  calling  conventions  and  run-time  organisation,  while 
Chapter  6  of  the  same  manual  describes  low-level  interfaces  and  assem¬ 
bly  language  modules. 


13.9 


Interface  to  Other  Languages 


13-19 


1 3.9a  XD  Ada  Import  and  Export  Pragmas 

XD  Ada  provides  import  and  export  pragmas  designed  specifi¬ 
cally  for  constructing  programs  composed  of  both  Ada  and  non- 
Ada  entities.  The  import  pragmas  allow  an  Ada  program  to  refer 
to  entities  written  in  another  language;  the  export  pragmas  make 
Ada  entities  available  to  programs  written  in  other  languages. 

The  names  of  the  pragmas  indicate  the  kind  of  entity  involved: 
IMPORT  FUNCTION  and  EXPORT.FUNCTION  apply  to  nongeneric 
functions;  IMPORT.PROCEDURE  and  EXPORT.PROCEDURE  apply  to 
nongeneric  procedures;  IMPORT_OBJECT  and  EXPORT_OBJECT  apply 
to  objects;  and  IMPORT_ EXCEPTION  and  EXPORT_EXCEPTION  apply 
to  exceptioTu.  These  pragmas  are  described  in  this  section,  summarized 
in  Aimex  B,  and  listea  in  Appendix  F. 

All  the  XD  Ada  import  and  export  pragmas  have  the  foilo%ving  form: 

prafM  lBport_export_pragma_nams 

( lntarnal_naaa  (,  external_deaignator ) 

(,  pragma_apecif ic_optiona) ) ; 

liapoTt_«cport_pra^a_name  1 1  - 

BZFORT  BXCtPTION  |  BXPORT_ FUNCTION 
I  BXPORt'oBJBCT  I  BXPORT~PROCBDORB 
IMPOfrr'BXCBPTION  I  1MI>ORT_FUNCTION 
I  IMP0RT~0BJBCT  I  IMPORT_PROCBDORB 

Internal  naaw  tt*  ( INTBRNAX,  «>]  alBiple_nan0 

I  (INTBRNAL  >7)  operator  aymbol  -•  Can  be  uaed  only  for 

—  IHPORT_FUNCTION 

external.deaisnator  si-  [BXTBRNAL  »)  external_aynbol 

external.syNbol  ii’*  identifier  |  etrlng^literal 

The  intenuil  name  can  be  an  Ada  simple  name,  or,  if  the  declared  entity 
is  a  function,  the  internal  name  can  be  a  string  literal  that  denotes  an 
operator  symbol.  A  subprogram  to  be  imported  or  exported  must  be 
identified  by  its  internal  name  and  parameter  types;  and,  in  the  case  of 
a  function,  by  the  result  type  (see  Section  13.9a.l.l). 

The  external  designator  determines  a  symbol  that  is  referenced  or 
declared  in  the  linker  object  module.  If  an  identifier  is  given,  the 
identifier  is  used.  U  a  string  literal  is  given,  the  value  of  the  string  is 
used.  The  value  of  a  string  literal  must  be  a  symbol  that  is  acceptable 
to  the  XD  Ada  Builder;  it  need  not  be  valid  as  an  Ada  identifier.  (For 
example,  the  dollar  character  ($)  can  be  used.)  If  no  external  designator 
is  given,  the  intenud  name  is  used  as  the  external  designator.  If  the 
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external  designator  (explicit  or  default)  is  longer  than  12  characters,  the 
import  or  export  pragma  is  ignored. 

Pragma-specific  options  are  described  in  the  individual  praema  sections 
that  follow. 

The  XD  Ada  import  and  export  pragmas  are  only  allowed  at  the  place 
of  a  declarative  item,  and  must  apply  to  an  entity  declared  by  an  earlier 
declarative  item  of  the  same  declarative  part  or  package  specification. 

At  most  one  import  or  export  pragma  is  allowed  for  any  given  entity;  in 
the  case  of  multiple  overloaded  subprograms,  this  rule  applies  to  each 
subprogram  independently. 

Additional  placement  and  usage  rules  apply  for  particular  pragmas  as 
described  in  the  following  sections. 

Not*: 


Argument  associations  for  XD  Ada  import  and  export  pragmas  can  be 
either  positional  or  named.  With  positional  association,  the  arguments 
are  interpreted  in  the  order  in  which  they  appear  in  the  S)mtax  detini- 
tion.  The  rules  for  the  mixing  of  positional  and  lumed  association  are 
the  same  as  those  that  apply  to  subprograms  (see  Section  6.4  (LRM)). 

A  pragma  for  an  entity  declared  in  a  package  specification  must  not  be 
given  in  the  package  body.  (A  pragma  for  an  entity  given  in  the  visible 
p^  of  a  package  specification  can,  however,  be  given  in  either  the 
visible  or  private  p^  of  the  specification.) 

No  checking  is  provided  to  ensure  that  exported  symbols  do  not  con¬ 
flict  with  each  other  or  with  other  global  symbols;  such  checking  is 
performed  by  the  XD  Ada  Builder. 


I3.9a.1  Importing  and  Exporting  Subprograms 

XD  Ada  provides  a  series  of  pragmas  that  make  it  possible  to  call 
nongeneric  subprc^ams  in  a  mixed-language  programming  environ¬ 
ment.  The  IMPORT.FUNCnON  and  IMPORT.PROCEDURE  pragmas 
specify  that  the  body  of  the  subprogram  associated  with  an  Ada  sub¬ 
program  specification  b  to  be  provided  from  assembly  language. 
Pragma  IhfTERFACE  must  precede  one  of  these  import  pragmas  (see 
Section  13.9).  The  EXPORT.FUNCTION  and  EXPORT.PROCEDURE 
pragmas  allow  an  Ada  procedure  or  function  to  be  call^  from  assem¬ 
bly  language.  The  pragjmas  support  parameter  passing  by  means  of 
roisters. 
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Importing  Subprograms 

XD  Ada  provides  two  pragmas  for  importing  subprograms: 
IMPORT.FUNCnON  and  IMPORT, PROCEDURE.  These  pragmas 
allow  the  impor*.  of  the  kind  of  subprograms  indicated. 

The  pragmas  for  importing  subprograms  have  the  following  form: 

pr««aa  IMPORT, FUNCTION  |  IMPORT, PROCEDURE 

((  INTERNAL  «>)  internal, name 
(,  (EXTERNAL  «>)  external,de8iqnator  ) 

(.  ( PARAMBTBR_TYPES  ->)  (  parameter, types  )  J 
(,  (RBSULT,TYPE  ->]  type,marlt  )  --  FUNCTION  only 

(,  I  MECHANISM  ->1  mechanism  J 

[,  [RBSULT_HECHANISM  -> )  mechanlsm,spec  )  —  FUNCTION  only 

(,  (PRaSERVED,REGISTERS  ->  )  (  registers  )  | 

); 

parameter, types  ii- 

sell  I  type_mark  {,  type,mark) 

mechanism  it- 

mechanism,spec  )  (  mechanism,spec  {,  mechanism_spec)  ) 
mechanism,spac  tt- 

mechanl sm,name  [  (  [REGISTER  ->  |  register_name  )  ] 

mechaniam_name  t i - 
value”  I 

REFERENCE  j  BIT,REFERENCe  | 

DOPE_VECTOR  j  BIt”dOPE,VECTOR 

registers  t><> 

eall  I  reglster,name  {,  register,name  } 

Functions  must  be  identifled  by  their  internal  names  and  parameter 
and  result  t)rpes.  The  parameter  and  result  types  can  be  omitted  only  if 
there  is  exactly  one  function  of  that  name  in  the  same  declarative  part  or 
package  specification.  Otherwise,  both  the  parameter  and  result  types 
must  be  specified. 

Procedures  must  be  identified  by  their  internal  names  and  parameter 
types.  The  parameter  types  can  be  omitted  only  if  there  is  exactly 
one  procedure  of  that  name  in  the  same  declarative  part  or  package 
specification.  Otherwise,  the  parameter  types  must  be  specified. 

The  external  designator  denotes  an  XD  Ada  Builder  global  symbol  that 
is  associated  with  the  external  subprogram.  If  no  external  designator  is 
given,  the  internal  name  is  used  as  the  global  symbol. 
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13.9a.  1.1 


The  parameter  types  option  specifies  a  series  of  one  or  more  t3rpe 
marlu  (t)rpe  or  subtype  names),  not  parameter  names.  Each  type  nrark 
is  positionally  associated  with  a  formal  parameter  in  the  subprogram's 
declaration.  The  absence  of  parameters  must  be  indicated  by  the 
reserved  word  null. 


The  result  type  option  is  used  only  for  functions;  it  specifies  the  type  or 
subtype  of  the  function  result. 

The  mechanism  option  specifies  how  the  imported  subprogram  expects 
its  parameters  to  be  passed  (for  example,  by  value,  by  reference  or 
by  descriptor).  The  calling  program  (namely  the  XD  Ada  program) 
is  responsible  for  ensuring  that  parameters  are  passed  in  the  form 
required  by  the  external  routine. 

Mechanism  names  are  described  as  follows.  Within  these  definitions, 
the  term  bit  string  means  any  one-dimensional  array  of  a  discrete  type 
whose  components  occupy  successive  single  bits.  The  term  simple 
record  type  means  a  record  type  that  does  not  have  a  variant  part  and  in 
which  any  constraint  for  each  component  and  subcomponent  is  static. 

A  simple  record  stdttype  is  a  simple  record  type  or  a  static  constrained 
subty^  of  a  record  type  (with  discriminants)  in  which  any  constraint  for 
each  component  and  subcomponent  of  the  record  type  is  static. 

Specifies  that  the  immediate  value  of  the  actual 
parameter  is  passed.  Values  of  scalars,  access 
types,  address  types  and  private  types  whose 
hill  type  is  either  a  scalar,  an  access  type  or  an 
address  type  can  be  passed  by  VALUE.  If  the 
value  is  a  private  type,  the  pragma  must  occur 
after  the  full  declaration  of  the  private  type.  Bit 
strings  can  also  be  passed  by  VALUE. 

Specifies  that  the  address  of  the  value  of  the 
actual  parameter  is  passed.  'This  mechanism  can 
be  used  for  parameters  of  any  type. 

Specifies  that  the  address  of  the  DOPE. VECTOR 
is  passed,  a  32-bit  pointer  to  an  object,  taking 
the  form  described  in  Section  2.1.4  of  the  XD 
Ada  MC68020  Run-Time  Reference  Manual. 

BIT_DOPE_ VECTOR  Specifies  that  the  address  of  the  BIT.DOPE. 

VECTOR  is  passed,  a  32-bit  pointer  to  an  oiriect, 
taking  the  form  described  in  Section  2.1.4  of  the 
XD  Ada  MC68020  Run-Time  Reference  Manual. 


VALUE 

REFERENCE 

DOPE.VECTOR 
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If  the  first  form  of  the  mechanism  option  is  given  (a  single  mechanism 
name  without  parentheses),  all  parameters  are  passed  using  that  mech¬ 
anism.  If  the  second  form  is  given  (a  series  of  mechanism  names  in 
parentheses  and  separated  by  commas),  each  mechanism  name  de¬ 
termines  how  the  parameter  in  the  same  position  in  the  subprogram 
specification  wrill  be  passed.  With  the  second  form,  each  parameter 
name  must  have  an  associated  mechanism  name. 

The  result  mechanism  option  is  used  only  for  functions;  it  specifies 
the  parameter-passing  mechanism  for  passing  the  result  type,  and 
optionally,  a  specific  register  used  to  pass  the  result. 

The  preserved  registers  option  gives  a  list  of  hardware  registers  which 
are  not  altered  by  the  procedure  or  function.  If  this  option  is  omitted  it 
implies  that  no  registers  are  preserved. 

In  addition  to  the  rules  given  in  Section  13.9a,  the  rules  for  importing 
subprograms  are  as  follows: 

•  If  an  import  pragma  is  given  for  a  subprogram  specification,  pragma 
INTERFACE  (see  Section  13.9)  must  also  be  given  for  the  subpro- 
gnun  earlier  in  the  same  declarative  part  or  package  specification. 
The  use  of  pragma  INTERFACE  implies  that  a  corresponding  body 
is  not  given. 

•  If  a  subprogram  has  been  declared  as  a  compilation  unit,  the 
pragma  is  only  allowed  after  the  subprogram  declaration  and  before 
any  subsequent  compilation  unit. 

•  These  pragmas  can  be  used  for  subprograms  declared  with  a  re¬ 
naming  declaration.  The  internal  name  must  be  a  simple  name,  and 
the  renaming  declaration  must  occur  in  the  same  declarative  part 
or  package  specification  as  the  pragma.  The  renamed  subprogram 
must  also  occur  in  that  same  declamtive  part  or  package  specifica¬ 
tion.  Renamed  subprograms  that  occur  outside  the  declarative  part 
or  package  specification  are  ignored  (without  a  warning  diagnostic). 

•  None  of  these  pragmas  can  be  used  for  a  generic  subprogram  or 
a  generic  subprogram  instantiation.  In  particular,  they  cannot  be 
used  for  a  subprogram  that  is  declared  by  a  generic  instantiation  of 
a  predefined  subprogram  (such  as  UNCHEC?CED_CONVERSION). 


13-34 


Importing  Subprograms  13.9a.1.1 


Examples: 

In  this  example,  the  pragma  INTERFACE  idenhfies  SQRT  as  an  external 
subprogram;  the  language  name  argument  ASSEMBLER  has  no  effect. 
The  pragma  IMPORT.FUNCTION  uses  positional  notation  to  specify 
arg^ents  for  importing  the  declared  function  SQRT.  The  pragma  form 
indicates  that  the  internal  name  is  SQRT,  and  the  external  designator  is 
'MTHSSQRT*.  The  parameter  is  of  type  FLOAT,  and  is  passed  in  FPl; 
the  result  is  of  type  FLOAT,  and  it  is  returned  in  FP2. 


faaetlea  SQRT  (X  t  FLOAT  )  ratura  FLOAT; 
prmgmm  INTERFACE  (ASSEMBLER,  SQRT); 
pra«Ba  IHPORT.FUNCTION 

(iQRT,  "MTHSSQRT",  (FLOAT), 
FLOAT,  (VALOE(FPl)),  VALUE(FP2) 
): 


The  next  example  shows  an  alternative  way  of  importing  the  declared 
function  SQRT  using  named  notation.  In  this  case,  the  parameter  is 
passed  in  FP5,  and  Ute  result  is  returned  in  FP4;  the  registers  which  are 
preserved  by  the  called  function  are  also  specified. 


faaatlea  SQRT  (X  i  LONG_FLOAT  )  ratura  LONG_FLOAT; 


praffsa  INTERFACE  (ASSEMBLER,  SQRT); 

pra^a  IMPORT_FUNCTION  (INTERNAL  •> 

PARAMBTER_TYPES  -> 

RESULT_TYPE  -> 

MECHANISM  -> 

RXSULT_MXCHANISM  -> 

EXTERNAL  -> 

PRESERVED  REGISTERS  -> 


SQRT, 

( LONG_FLOAT ) , 
LONG_ FLOAT, 
(VALUE(FP5) ) , 
VALUE  (  FP4  ) , 
"MTHSDSQRT", 


(DO,  Dl,  D2,  D3,  D4,  D5,  D6 , 


D7, 


AO,  Al,  A2,  A3,  A4,  AS, 

FPO,  FPl,  FP2,  FP3,  FP5,  FP6 ) ) ; 


If  the  previous  example  is  combined  with  the  code  in  the  first  example 
(that  is,  with  only  one  occurrence  of  pragma  INTERFACE),  the  result  is 
an  overloading  of  SQRT; 
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fuaetlOB  SORT  (X  :  LONG_FLOAT  )  ratura  LONG_FLOAT; 
faaetlea  SQRT  (X  :  FLOAT  )  ratura  FLOAT; 
pragma  INTERFACE  (ASSEMBLER,  SQRT | ; 
pragma  I MPORT_ FUNCTION  (SQRT, 

-MTHSSQRT", 

( FLOAT ) , 

FLOAT, 

(VALUE(FPl) ), 

VALUE(FP2) ); 

pragma  IMPORT_FUNCTION  (INTERNAL  ->  SQRT, 

PARAMETBR_TYPES  ->  ( LONG_ FLOAT ) , 

RBSULT_TYPE  ->  LONG_FLOAT, 

MECHANISM  ->  ( VALUE( FP5 ) ) , 

RBSULT_MBCHANISM  ->  VALUE ( FP4 ) , 

EXTBRNi^  ->  -MTHSDSQRT" , 

PRESBRVBD_RBGISTERS  -> 

(DO,  Dl,  D2,  D3,  D4,  D5,  D6,  D7 , 

AO,  Al,  A2,  A3,  A4,  AS, 

FPO,  FPl,  FP2,  FP3,  FP5,  FP6 ) ) ; 

The  next  example  shows  the  use  of  renaming  with  an  imported  pro¬ 
cedure  (it  is  assumed  that  these  declarations  occur  in  a  declarative 
part  or  package  specification).  Note  that  the  renaming  causes  the  im¬ 
ported  ASSEI^I^  procedure  to  be  used  in  calls  to  both  procedures 
CHANGE  and  EXCHANGE.  Also  note  that  because  no  external  desig¬ 
nator  is  specified,  the  builder  global  symbol  associated  with  the  extenud 
subprogram  is  EXCHANGE,  and  because  no  parameter  mechanisms 
are  specified,  the  compiler's  defaults  will  apply  in  calls  to  CHANGE  or 
EXCHANGE. 

proemdara  CHANGB  (X,Y  i  INTEGER); 

preeadara  EXCHANGE  (X,Y  i  INTEGER)  raaamaa  CHANGB; 

pragma  INTERFACE  (ASSEMBLER,  EXCHANGE); 

pragma  IMPORT. PROCEDURE  (INTERNAL  ->  EXCHANGE, 

PARAMETER.TYPBS  ->  ( INTEGER, INTEGER) ) ; 


13.9«.1.2  Exporting  Subprograms 

XD  Ada  provides  two  pragmas  for  exporting  subprograms: 
EXPORT.FUNCnON  an<i  EXPORT.PROCEDURE.  Both  export  prag¬ 
mas  establish  an  external  name  for  a  subprogram  and  make  the  name 
available  to  the  XD  Ada  Builder  as  a  global  symbol,  so  that  the  subpro¬ 
gram  can  be  called  by  an  assembly  language  module. 

The  EXPORT.FUNCnON  and  EXPORT.PROCEDURE  pragmas  allow 
the  export  of  the  kind  of  subprograms  indicated. 
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The  pragmas  for  exporting  subprograms  have  the  following  form: 


pragaa  EXPORT_ FUNCTION  |  EXPORT_PROCEDURE 

{  (  INTERNAL  •> ]  internal_name 

[,  (EXTERNAL  ->|  external_de8ignator  ) 

[,  { PARAMETER_TYPES  ■> )  (  paraineter_types  )  ) 

[,  [RESULT_TYPB  -> |  type_marX  ]  —  FUNCTION  only 

(,  (MECHANISM  ->(  mechaniam  ) 

[RBSULT_MECHANISM  -> )  mechaniBm_spec  ]  --  FUNCTION  only 

)!  " 


parameter_typeB  i!« 

Bull  I  type_inark  {,  type_mark> 

mechanlBin  >i- 

mechaniam_Bpec  [  (  inechanism_Bpec  (,  inechaniBm_Bpec }  ) 
mechanlBni_Bpec  si” 

mechaniBm_neune  (  (  (REGISTER  ->  )  reqiBter_name  )  ] 
mechanlBin_name  tt- 

valub”  I 

RBBBRBNCB  j  BIT_REFBRENCB  | 

DOPB_VBCTOR  j  BIT_DOPE_VBCTOR 

reglstera  t)- 

anil  I  re9later_najne  {,  regiater_naine  ) 

paraiiiatar_typea  ii** 

aall  I  type_mark  (,  type_mark} 

Functions  must  be  identified  by  their  internal  names  and  parameter 
and  result  types.  The  parameter  and  result  types  can  be  omitted  only  if 
there  is  exactly  one  function  of  that  name  in  the  same  declarative  part  or 
package  specification.  Otherwise,  both  the  parameter  and  result  types 
must  be  specified. 

Procedures  must  be  identiAed  by  their  internal  names  and  parameter 
t)rpes.  The  parameter  types  can  be  omitted  only  if  there  is  exactly 
one  procedure  of  that  name  in  the  same  declarative  part  or  package 
specification.  Otherwise,  the  parameter  types  must  be  specified. 

The  external  designator  denotes  an  XD  Ada  Builder  global  symbol 
that  is  associated  with  the  external  subprogram.  If  no  external  name  is 
given,  the  internal  name  is  used  as  the  global  symbol. 

The  parameter  types  option  speciHes  a  series  of  one  or  more  type 
marks  (type  or  subtype  names),  not  parameter  names.  Each  type  mark 
is  positioiuilly  associated  with  a  formal  parameter  in  the  subprogram's 
declaration.  The  absence  of  parameters  must  be  indicat  d  by  the 
reserved  word  null. 
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The  result  type  option  is  used  only  for  functions;  it  specifies  the  type  or 
subtype  of  the  function  result. 

The  mechanism  option  specifies  how  the  imported  subprogram  expects 
its  parameters  to  be  passed  (for  example,  by  value,  by  reference  or 
by  descriptor).  The  calling  program  (namely  the  XD  Ada  program) 
is  responsible  for  ensuring  that  parameters  are  passed  in  the  form 
required  by  the  external  routine.  Mechanism  options  and  possible 
values  for  mechanism  names  and  class  names  are  described  in  Section 
13.9a.l.l. 

If  the  first  form  of  the  mechanism  option  is  given  (a  single  mechanism 
name  without  parentheses),  all  parameters  are  passed  using  that  mech¬ 
anism.  If  the  second  form  is  given  (a  series  of  mechanism  names  in 
parentheses  and  separated  by  commas),  each  mechanism  name  de¬ 
termines  how  the  parameter  in  the  same  position  in  the  subprogram 
specification  will  be  passed.  With  the  second  form,  each  parameter 
name  must  have  an  associated  mechanism  name. 

The  result  mechanism  option  is  used  only  for  functions;  it  specifies 
the  parameter-passing  mechanism  for  passing  the  result  type,  and 
optionally,  a  specific  register  used  to  pass  the  result. 

In  addition  to  the  rules  given  in  Section  13.9a,  the  rules  for  exporting 
subprograms  are  as  follows; 

•  An  exported  subprogram  must  be  a  library  unit  or  be  declared  in 
the  outermost  declarative  part  of  a  library  package.  Thus,  pragmas 
for  exporting  subprograms  are  allowed  only  in  the  following  cases: 

—  For  a  subprogram  specification  or  a  subprogram  body  that  is  a 
library  unit 

—  For  a  subprogram  specification  that  is  declared  in  the  outermost 
declarations  of  a  package  specification  or  a  package  body  that  is 
a  library  unit 

—  For  a  subprogram  body  that  is  declared  in  the  outermost  decla¬ 
rations  of  a  package  body  that  is  a  library  urrit 

Consequently,  an  export  pragma  for  a  subprogram  body  is  allowed 
only  if  either  the  body  does  not  have  a  corresponding  specification, 
or  the  specification  and  body  occur  in  the  same  declarative  part. 

This  set  of  rules  implies  that  an  EXPORT.FUNCTION  or 
EXPORT_PROCEDURE  pragma  cannot  be  given  for  a  generic  li¬ 
brary  subprogram,  nor  can  one  be  given  for  a  subprogram  declared 
in  a  generic  library  package.  However,  either  of  these  pragmas 
can  be  given  for  a  subprogram  resulting  from  the  instantiation  of 
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a  generic  subprogram,  provided  that  the  instantiation  otherwise 
satisfies  this  set  of  rules. 

•  In  the  case  of  a  subprogram  declared  as  a  compilation  unit,  the 
pragma  is  only  allowed  after  the  subprogram  declaration  and  before 
any  subsequent  compilation  unit. 

•  Neither  of  these  pragmas  can  be  used  for  a  subprogram  that  is 
declared  with  a  renaming  declaration. 

•  Neither  of  these  pragmas  can  be  used  for  a  subprogram  that  is 
declared  by  a  generic  instantiation  of  a  built-in  library  subprogram 
(such  as  UNCHECKED_CONVERSION). 

Examples: 

The  following  example  shows  an  export  pragma  that  causes  the  Ada 
procedure  PROC  to  be  exported  for  use  in  an  assembly  language 
module.  The  irame  PROC  is  declared  as  an  XD  Ada  Builder  global 
symbol. 

pree«aara  PROC  (Y  t  INTEGER); 
pra«M  EXPORT.PROCEOURS  (PRCC); 

The  next  example  shows  an  Ada  function  being  called  from  an  assembly 
language  module; 

faaetiOB  HULXrr'Y  (Y  i  la  INTEGER)  ratura  INTEGER  la 

ba«la 

ratara  Y  •  10; 

aa4; 

prapiui  EXPORT_PUNCTtON  (  INTERNAL  «>  MULriPLY, 

PARAMETER_TYPES  ->  (INTEGER), 

RESULT_TYPE  ->  INTEGER  ); 

pra«wi  CALL_SEQUENCB_ FUNCTION  ( 

UNIT  ->  MULTIPLY, 

PARAMBTER_TyPES  ->  (INTEGER), 
mechanism"  ->  (VALUE(l>0)  ) , 

RESULT_MECHANISM  ->  VALUE(DO)); 


TITLE  •MC68020  Calling  Ada" 
MODULE  •CALL_ADA* 

XDEF  CALL_ADA 
XREF  MULTIPLY 

OSEG 

A  BLKB  4  I  An  INTEGER 

PSEG 
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CALL_ADA 


MOVE , L 

tl,A  1 

t  A  1; 

MOVE . L 

A,  DO 

JSR 

MULTIPLY. L 

MOVE . L 
RTS 

DO, A  1 

1  A  MULTIPLY^ 

END 

13.9a.2  importing  and  Exporting  Objects 

XD  Ada  provides  two  pragmas  for  importing  and  exporting  objects: 
IMPORT.OBJECT  and  EXPORT.OBJECT.  The  IMPORT.OBJECT 
pngma  references  storage  declared  in  an  assembly  language  module. 
The  EXPORT.OBJECT  pragma  allows  an  assembly  language  module  to 
refer  to  the  storage  allocated  for  an  Ada  object. 

In  addition  to  the  rules  given  in  Section  13.9a,  the  rules  for  importing 
and  exporting  objects  are  as  follows: 

•  The  object  to  be  imported  or  exported  must  be  a  variable  declared 
by  an  object  declaration  at  the  outermost  level  of  a  library  package 
specification  or  body. 

•  The  subt3rpe  indication  of  an  object  to  be  imported  or  exported  must 
denote  one  of  the  following: 

—  A  scalar  type  or  subtype. 

—  An  array  subtype  with  static  index  constraints  whose  component 
size  is  static. 

—  A  record  type  or  subtype  that  does  not  have  a  variant  part  and 
in  which  any  constraint  for  each  component  and  subcomponent 
is  static  (a  simple  record  type  or  subtype). 

•  Import  and  export  pragmas  are  not  allowed  for  objects  declared 
with  a  renaming  declaration. 

•  Import  and  export  pragmas  for  objects  are  not  allowed  in  a  generic 
unit. 
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Notes: 


Objects  of  private  or  limited  private  tjrpes  cannot  be  imported  or 
exported  outside  the  package  that  declares  the  (limited)  private  type. 
They  can  be  imported  or  exported  inside  the  body  of  the  package  where 
the  type  is  declared  (that  is.  where  the  full  type  is  known). 

The  XD  Ada  pragmas  for  importing  or  exporting  objects  can  precede  or 
follow  a  pragma  VOLATILE  for  the  same  objects  (see  Section  9.11). 

Address  clauses  are  not  allowed  in  combination  with  any  of  the  XD  Ada 
pragmas  for  importing  or  exporting  objects.  If  used  in  such  cases,  the 
pragma  involved  is  ignored  (see  Section  13.5). 


I3.9a.2.1  Importing  Objects 

The  XD  Ada  IMPORT_OBJECT  pragma  specifies  that  the  storage  allo¬ 
cated  for  the  object  (when  the  assembly  language  module  is  compiled) 
be  made  known  to  the  calling  Ada  program  by  an  externally-defined 
Ada  Builder  global  symbol. 

Pragma  IMPORT_OBJECT  has  the  following  form: 

pn«aa  IHPORT_OBJSCT 

( lnternal_naiiie  [,  external_deBlqn«tor ) ) 

The  internal  name  is  the  object  identifier.  The  external  designator 
denotes  an  XD  Ada  Builder  global  symbol  that  is  associated  with  the 
external  object.  If  no  external  designator  is  given,  the  internal  name  is 
used  as  the  global  symbol. 

Because  it  is  not  created  by  an  Ada  elaboration,  an  imported  object 
cannot  have  an  initial  value.  Specifically,  this  restriction  means  that  the 
object  to  be  imported; 

•  Caimot  be  a  constant  (have  an  explicit  initial  value). 

•  Cannot  be  an  access  type  (which  has  a  default  initial  value  of  null). 

•  Cannot  be  a  record  type  that  has  discriminants  (which  are  always 
initialized)  or  components  with  default  initial  expressions. 

•  Cannot  be  an  object  of  a  task  type. 
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Example 

PIDi  INTEGER; 

pra«M  IMPORT_OBJECT  (PID,  “PROCESSSID"  )  ; 

In  this  example,  the  variable  PID  refers  to  the  externally-defined  symbol 
PROCESSSID. 

Alternatively,  this  example  can  be  written  in  named  notation  as  follows: 

PID  ■  INTEGER; 

prm^mm  IMPORT_OBJBCT  (INTBRNAL  ->  PID, 

EXTERNAL  ->  "PROCESSSID*); 


13.9a.2.2  Exporting  Objeela 

The  XD  Ada  pragma  EXPORT_OBJECT  specifies  that  the  storage  al¬ 
located  for  the  object  (when  the  Ada  pro^am  is  compiled)  be  made 
known  to  assembly  language  modules  by  an  XD  Ada  Builder  global 
symbol. 

Pragma  EXPORT_OBJECT  has  the  following  form: 

pvmfmm  BXPORT_OBJSCT 

( lnt«rnal_name  (>  external_dealgnator ) ) 

The  internal  rume  is  the  object  identifier.  The  external  designator 
denotes  an  XD  Ada  Builder  global  symbol  that  is  associated  with  the 
external  object.  If  no  external  designator  is  given,  the  internal  name  is 
used  as  the  global  symbol. 

Exampio: 

PIDI  INTEGER; 

rra«Ba  EXPORT_OBJRCT  (PID,  "PROCESSSID" )J 

Alternatively,  this  example  can  be  written  in  named  notation: 

Plot  INTBGERl 

pra«ma  BXPORT_OBJBCT  (INTERNAL  ->  PID, 

EXTERNAL  ->  "PROCESSSID"); 
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13. 9a. 3  Importing  and  Exporting  Exceptions 

XD  Ada  provides  the  IMPORT.EXCEPTION  and  EXPORT.EXCEPTION 
pragmas  for  importing  and  exporting  exceptions.  The  pragma  IMPORT. 
EXCEPTION  allows  non-Ada  exceptions  to  be  used  in  Ada  programs; 
the  pragma  EXPORT.EXCEPTION  allows  Ada  exceptions  to  be  used  by 
foreign  units. 

The  rules  for  importing  and  exporting  exceptions  are  given  in  Section 
13.9a. 

Not*: 

A  pragma  for  an  exception  that  is  declared  in  a  package  specification  is 
not  allowed  in  the  package  body. 


13.9a.3.l  Importing  Exception* 

The  XD  Ada  IMPORT.EXCEPTION  pragma  is  provided  for  compatibil¬ 
ity  with  VAX  Ada.  This  pragma  specifies  that  the  exception  associated 
with  an  exception  declaration  in  an  Ada  program  be  defined  extenrally 
in  non-Ada  code. 

In  XD  Ada  pragma  IMPORT.EXCEPTION  has  the  following  form: 

prafM  IHPORT.EXCEPTION 

( internal.nane  (,  external.deaignator ] 

(,  (FORM  ->|  ADA  )); 

The  internal  name  must  be  an  Ada  identifier  that  denotes  a  declared 
exception.  The  external  designator  denotes  an  XD  Ada  Builder  global 
symbol  to  be  used  to  refer  to  the  exception.  If  no  extental  name  is 
given,  the  intental  name  is  used  as  the  global  symbol. 

For  compatibility  with  VAX  Ada,  the  form  option  indicates  that  an  Ada 
exception  is  being  imported.  If  omitted,  this  defaults  to  ADA. 

The  external  designator  refers  to  an  address  that  identifies  the  excep¬ 
tion. 

The  VAX  Ada  version  of  this  pragma  supports  an  alternative  form 
(VMS),  and  a  code  option  in  addition  to  the  XD  Ada  arguments.  If 
either  of  these  unsupported  arguments  is  specified,  the  compiler  ignores 
the  pragma  and  issues  a  warning  message. 


Importing  Exceptions  13.9a.3.l 
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13.9a.3.2  Exporting  Excaption* 

The  XD  Ada  EXP0RT_EXCEPT10N  pragma  allows  Ada  exceptions  to 
be  visible  outside  the  XD  Ada  program,  so  that  they  can  be  raised  and 
handled  by  programs  written  in  XD  Ada  MC68020  assembly  language. 
This  pragma  establishes  an  external  name  for  an  Ada  exception  and 
makes  the  name  available  to  the  XD  Ada  Builder  as  a  global  symbol. 
Refer  to  the  XD  Ada  MC68020  Run-Time  Reference  Manual  for  further 
information  on  exporting  exceptions. 

Pragma  EXPORT.EXCEPTION  has  the  following  form: 

pr««u  exPORr_EXCBPTION 

( internal^name  (»  externa^ ^designator ) 

[ p  [ FORM  -> I  ADA  ] ) ; 

The  internal  name  must  be  an  Ada  identifier  that  denotes  a  declared 
exception.  The  external  designator  denotes  an  XD  Ada  Builder  global 
symbol  to  be  used  to  refer  to  the  exception. 

The  form  option  specifies  that  an  Ada  exception  is  being  exported. 

ExampI*: 

UNDBRTLOW  t  •aeaptlM 

pra«M  BXP0RT_BXCBPT10N  (UNDERFLOW,  HTH_UNDBRFLOW,  ADA); 

In  this  example,  an  Ada  exception  is  exported  as  a  global  symbol. 
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13.10  Unchecked  Programming 


13.10.1  Unchecked  Storage  Deallocation 

The  following  information  supplements  the  Notes  section: 

Because  UNCHECKED_DEALLOCATION  is  a  predefined  generic  pro¬ 
cedure,  XD  Ada  does  not  allow  the  use  of  the  lMPORT_PROCEDURE 
pragma  to  substitute  an  alternative  procedure  body. 


13.10.2  Uncheoked  Type  Conversions 

The  following  information  supplements  paragraph  2: 

XD  Ada  supports  the  generic  function  UNCHECKED_CONVERSION 
with  the  following  restiictioiu  on  the  class  of  types  involved: 

•  The  actual  subtype  corresponding  to  the  formal  type  TARGET  must 
not  be  an  unconstrained  array  type. 

•  The  actual  subtype  corresponding  to  the  formal  type  TARGET  must 
not  be  an  unconstrained  type  with  discriminants. 

Further,  when  the  target  type  is  a  type  with  discriminants,  the  value 
resulting  from  a  call  of  the  conversion  function  resulting  from  an  instan¬ 
tiation  of  UNCHECKED.CONVERSION  is  checked  to  ensure  that  the 
discrindnants  satisfy  the  coiutraints  of  the  actual  subtype. 

The  effect  with  XD  Ada  is  as  if  the  source  value  is  copied  one  byte 
in  ascending  order  of  address,  into  the  destination,  also  in  ascending 
order  of  address.  If  the  destination  has  fewer  bytes  than  the  source 
value,  the  high  order  bytes  of  the  source  value  are  ignored  (truncated). 
If  the  source  value  has  fewer  bytes  than  the  destination,  the  high  order 
bytes  of  the  destiiuition  are  set  to  zero. 
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